j'ai fait ma version de liste chainée nommée 'list', et j'ai décidé de
faire un autre "objet" 'vect' qui serait une liste chainée list avec
des caractéristiques en plus...
en gros, c'est une structure avec une 'list' dedans et d'autres
choses....
maintenant, l'utilisateur est en droit d'attendre que le 'vect'
présente les même possibilités que la 'list', c'est à dire
ajouter/retirer des élements, rechercher, se déplacere etc...
cependant, la 'list' du 'vect' est présente dans la structure sous
forme de pointeur, et cette structure n'est PAS accessible a
l'utilisateur (en quelque sorte, elle est private)
ma question est donc : comment présenter dans l'interface du 'vect' les
caractéristiques de la 'list' sans :
- refaire toute l'interface 'list' dans le module 'vect'
- donner à l'utilisateur l'accès au pointeur list* de la structure
vect.
(car une solution simple serait de faire une sorte d'accesseur :
list_t *vect_GetList(vect_t *v)
{
return v->pl; //donne la main sur la liste
}
mais ça serait contraire à l'esprit du code qui veut cacher tous ces
détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et
déterminée.)
[ accesseur ] mais ça serait contraire à l'esprit du code qui veut cacher tous ces détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se trouve au niveau des specs : il va couter un appel de fonction bien inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ; conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
A par ca tu as raison, les accesseurs c'est Mal.
Nicolas Aunai wrote:
[ accesseur ]
mais ça serait contraire à l'esprit du code qui veut cacher tous ces
détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et
déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail
d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en
avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait
déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il
veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se
trouve au niveau des specs : il va couter un appel de fonction bien
inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta
structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ;
conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
[ accesseur ] mais ça serait contraire à l'esprit du code qui veut cacher tous ces détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se trouve au niveau des specs : il va couter un appel de fonction bien inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ; conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
A par ca tu as raison, les accesseurs c'est Mal.
DINH Viêt Hoà
j'ai fait ma version de liste chainée nommée 'list', et j'ai décidé de faire un autre "objet" 'vect' qui serait une liste chainée list avec des caractéristiques en plus...
struct list { ... };
struct autre_objet_heritant_de_list { struct list super; ... };
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
cf la page de Laurent Deniau sur la programmation orientée objet en C. Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
j'ai fait ma version de liste chainée nommée 'list', et j'ai décidé de
faire un autre "objet" 'vect' qui serait une liste chainée list avec
des caractéristiques en plus...
struct list {
...
};
struct autre_objet_heritant_de_list {
struct list super;
...
};
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de
liste.
cf la page de Laurent Deniau sur la programmation orientée objet en C.
Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
--
DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
j'ai fait ma version de liste chainée nommée 'list', et j'ai décidé de faire un autre "objet" 'vect' qui serait une liste chainée list avec des caractéristiques en plus...
struct list { ... };
struct autre_objet_heritant_de_list { struct list super; ... };
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
cf la page de Laurent Deniau sur la programmation orientée objet en C. Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
Nicolas Aunai
Le 24/06/2004, DINH Viêt Hoà a supposé :
struct list { ... };
struct autre_objet_heritant_de_list { struct list super; ... };
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast... que se passe-t-il vraiment avec ce cast ?
cf la page de Laurent Deniau sur la programmation orientée objet en C.
ok,dont voici l'url : http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html je vais essayer de lire un peu de tout ça merci
Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
[ accesseur ] mais ça serait contraire à l'esprit du code qui veut cacher tous ces détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se trouve au niveau des specs : il va couter un appel de fonction bien inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ; conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
A par ca tu as raison, les accesseurs c'est Mal.
Chapitre et verset, svp ?
Nicolas Aunai wrote:
[ accesseur ]
mais ça serait contraire à l'esprit du code qui veut cacher tous ces
détails à l'utilisateur, pour ne lui présenter qu'une interface fixe
et déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail
d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en
avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait
déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il
veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se
trouve au niveau des specs : il va couter un appel de fonction bien
inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta
structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ;
conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
[ accesseur ] mais ça serait contraire à l'esprit du code qui veut cacher tous ces détails à l'utilisateur, pour ne lui présenter qu'une interface fixe et déterminée.)
Non, le fait qu'il y ait une liste dans ton vect ce n'est pas un détail d'implémentation à cacher à l'utilisateur. Au contraire, tu le met en avant quant tu dis que vect "hérite" de list. Donc, l'utilisateur sait déjà qu'il y a une list dans chaque vect, c'est pourquoi d'ailleurs il veut se servir de son vect comme d'une liste.
Donc ne pas hésiter à faire un accesseur, dont le seul inconvénient se trouve au niveau des specs : il va couter un appel de fonction bien inutile. C'est pourquoi tu devrais dans ce cas définir publiquement ta structure vect dans le eader et faire un accesseur inline.
En fait, dans ce cas ce n'est pas vraiment un accesseur ; conceptuelement, c'est plutôt un 'cast' équivalent aux "::" du C++.
A par ca tu as raison, les accesseurs c'est Mal.
Chapitre et verset, svp ?
DINH Viêt Hoà
struct list { ... };
struct autre_objet_heritant_de_list { struct list super; ... };
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de autre_objet_heritant_de_list est identique à list, on peut faire les mêmes appels, faut éventuellement l'appel qui va libérer la structure mémoire.
Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
certainement au dela de mon niveau ;-)
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais c'est simple en tout cas.
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
struct list {
...
};
struct autre_objet_heritant_de_list {
struct list super;
...
};
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de
liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de
autre_objet_heritant_de_list est identique à list, on peut
faire les mêmes appels, faut éventuellement l'appel qui va libérer
la structure mémoire.
Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
certainement au dela de mon niveau ;-)
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais
c'est simple en tout cas.
--
DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
struct autre_objet_heritant_de_list { struct list super; ... };
struct autre_objet_heritant_de_list * objet;
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de autre_objet_heritant_de_list est identique à list, on peut faire les mêmes appels, faut éventuellement l'appel qui va libérer la structure mémoire.
Tu peux aussi regarder l'implémentation de Glib/GTK, etc.
certainement au dela de mon niveau ;-)
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais c'est simple en tout cas.
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
Nicolas Aunai
DINH Viêt Hoà a pensé très fort :
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
ok :-)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de autre_objet_heritant_de_list est identique à list, on peut faire les mêmes appels, faut éventuellement l'appel qui va libérer la structure mémoire.
ok
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais c'est simple en tout cas.
oui bon, tout est relatif bien sûr...
j'ajoute juste que j'ai lu en diagonale la page de Laurent Deniau, ouah c'est un peu un "truc de ouf", quand je parlais d'héritage, et donc implicitement de programmation *orientée* objet, c'était dans l'esprit, la logique, l'organisation et la manipulation des données y ressemble..
quant à calquer exactement la programmation objet par un nombre incalculables de technique-bidouilles-combines et autres astuces je trouve ça très lourd et pense tout de même que celà doit etre assez /rarement/ utilisé !
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
ok :-)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de
autre_objet_heritant_de_list est identique à list, on peut
faire les mêmes appels, faut éventuellement l'appel qui va libérer
la structure mémoire.
ok
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais
c'est simple en tout cas.
oui bon, tout est relatif bien sûr...
j'ajoute juste que j'ai lu en diagonale la page de Laurent Deniau, ouah
c'est un peu un "truc de ouf", quand je parlais d'héritage, et donc
implicitement de programmation *orientée* objet, c'était dans l'esprit,
la logique, l'organisation et la manipulation des données y ressemble..
quant à calquer exactement la programmation objet par un nombre
incalculables de technique-bidouilles-combines et autres astuces je
trouve ça très lourd et pense tout de même que celà doit etre assez
/rarement/ utilisé !
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
oui, mais c'est caché par l'interface ;)
ok :-)
que se passe-t-il vraiment avec ce cast ?
et bien, comme le début de la représentation mémoire de autre_objet_heritant_de_list est identique à list, on peut faire les mêmes appels, faut éventuellement l'appel qui va libérer la structure mémoire.
ok
heu ... oui, enfin c'est nul glib/GTK, enfin pas nul mais c'est simple en tout cas.
oui bon, tout est relatif bien sûr...
j'ajoute juste que j'ai lu en diagonale la page de Laurent Deniau, ouah c'est un peu un "truc de ouf", quand je parlais d'héritage, et donc implicitement de programmation *orientée* objet, c'était dans l'esprit, la logique, l'organisation et la manipulation des données y ressemble..
quant à calquer exactement la programmation objet par un nombre incalculables de technique-bidouilles-combines et autres astuces je trouve ça très lourd et pense tout de même que celà doit etre assez /rarement/ utilisé !
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast... que se passe-t-il vraiment avec ce cast ?
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace ?? Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast après tout. Tu peux même te passer des parenthèses extérieure, si ça t'arrange, dans la plupart des cas. Quant au critère esthétique, euh...
"Nicolas Aunai" <nicolas.aunai@free.fr> a écrit dans le message de
news:mn.c5837d467a490feb.1437@free.fr...
((list *) objet) donnera un objet list manipulable par les fonctions de
liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast...
que se passe-t-il vraiment avec ce cast ?
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace
?? Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast
après tout. Tu peux même te passer des parenthèses extérieure, si ça
t'arrange, dans la plupart des cas.
Quant au critère esthétique, euh...
((list *) objet) donnera un objet list manipulable par les fonctions de liste.
ouais mais alors je trouve pas ça beau du tout ce vilain cast... que se passe-t-il vraiment avec ce cast ?
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace ?? Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast après tout. Tu peux même te passer des parenthèses extérieure, si ça t'arrange, dans la plupart des cas. Quant au critère esthétique, euh...
Nicolas Aunai
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace ??
les deux mon... capitaine..
Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast après tout. Tu peux même te passer des parenthèses extérieure, si ça t'arrange, dans la plupart des cas. Quant au critère esthétique, euh...
c'est important, les meilleures solutions sont souvent les plus belles :-)
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace
??
les deux mon... capitaine..
Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast
après tout. Tu peux même te passer des parenthèses extérieure, si ça
t'arrange, dans la plupart des cas.
Quant au critère esthétique, euh...
c'est important, les meilleures solutions sont souvent les plus belles
:-)
Est-ce que tu fais du code pour qu'il soit beau, ou pour qu'il soit efficace ??
les deux mon... capitaine..
Que tu ne trouves ça pas très lisible, soit, mais ce n'est qu'un cast après tout. Tu peux même te passer des parenthèses extérieure, si ça t'arrange, dans la plupart des cas. Quant au critère esthétique, euh...
c'est important, les meilleures solutions sont souvent les plus belles :-)
quant à calquer exactement la programmation objet par un nombre incalculables de technique-bidouilles-combines et autres astuces je trouve ça très lourd et pense tout de même que celà doit etre assez /rarement/ utilisé !
ce que fait Laurent Deniau est cependant un peu extreme (comme le groupe de rock'n roll).
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
quant à calquer exactement la programmation objet par un nombre
incalculables de technique-bidouilles-combines et autres astuces je
trouve ça très lourd et pense tout de même que celà doit etre assez
/rarement/ utilisé !
ce que fait Laurent Deniau est cependant un peu extreme (comme le groupe
de rock'n roll).
--
DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
quant à calquer exactement la programmation objet par un nombre incalculables de technique-bidouilles-combines et autres astuces je trouve ça très lourd et pense tout de même que celà doit etre assez /rarement/ utilisé !
ce que fait Laurent Deniau est cependant un peu extreme (comme le groupe de rock'n roll).
-- DINH V. Hoa,
"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
Jean-Noël Mégoz
"Nicolas Aunai" a écrit dans le message de news:
c'est important, les meilleures solutions sont souvent les plus belles :-)
Il faut s'entendre sur ce qui fait un code "beau" ou "meilleur" !
Utiliser des bidouilles de ouf, très bas niveau, pour effectuer de manière très efficace (et le + svt non portable) une tâche précise, il y en a qui trouvent ça beau. Pour moi, la lisibilité du code est en général plus importante (je dis bien en général ! Dans des applis temsp-réel, par exemple, c'est différent). Parce que le programme mettra peut-être 1 ou 2 secondes de + à faire son boulot, mais l'utilisateur ne s'en rendra même pas compte. Par contre, le programmeur qui reprendra le code quelques mois ou années après, perda énormément moins de temps s'il n'a pas à chercher pourquoi ceci ou cela...
"Nicolas Aunai" <nicolas.aunai@free.fr> a écrit dans le message de
news:mn.c81c7d4634270d40.1437@free.fr...
c'est important, les meilleures solutions sont souvent les plus belles
:-)
Il faut s'entendre sur ce qui fait un code "beau" ou "meilleur" !
Utiliser des bidouilles de ouf, très bas niveau, pour effectuer de manière
très efficace (et le + svt non portable) une tâche précise, il y en a qui
trouvent ça beau. Pour moi, la lisibilité du code est en général plus
importante (je dis bien en général ! Dans des applis temsp-réel, par
exemple, c'est différent). Parce que le programme mettra peut-être 1 ou 2
secondes de + à faire son boulot, mais l'utilisateur ne s'en rendra même pas
compte.
Par contre, le programmeur qui reprendra le code quelques mois ou années
après, perda énormément moins de temps s'il n'a pas à chercher pourquoi ceci
ou cela...
c'est important, les meilleures solutions sont souvent les plus belles :-)
Il faut s'entendre sur ce qui fait un code "beau" ou "meilleur" !
Utiliser des bidouilles de ouf, très bas niveau, pour effectuer de manière très efficace (et le + svt non portable) une tâche précise, il y en a qui trouvent ça beau. Pour moi, la lisibilité du code est en général plus importante (je dis bien en général ! Dans des applis temsp-réel, par exemple, c'est différent). Parce que le programme mettra peut-être 1 ou 2 secondes de + à faire son boulot, mais l'utilisateur ne s'en rendra même pas compte. Par contre, le programmeur qui reprendra le code quelques mois ou années après, perda énormément moins de temps s'il n'a pas à chercher pourquoi ceci ou cela...
