Si j'ai bien compris l'histoire, un handler est l'=E9mulation d'un
pointeur constant. Ma question est donc simple : pourquoi ne pas
utiliser un pointeur constant ? J'imagine qu'il doit y avoir des
exemples standards.
Sinon, est il *toujours* pr=E9f=E9rable d'impl=E9menter une classe handler
plutot que de renvoyer des pointeurs constants ? Et si oui, pourquoi ?
Si j'ai bien compris l'histoire, un handler est l'émulation d'un pointeur constant.
Handler, c'est un mot sans signification très précis. On s'en sert quand on ne trouve pas de meilleur mot pour décrire ce que fait la classe. C'est un peu comme « Manager » à cet égard : la différence, c'est qu'en général, on s'attend à ce qu'un handler réagisse à quelque chose d'extérieur. C'est souvent le cas aussi des managers, mais les handlers réagissent plus directement.
Je ne vois pas de rapport avec un pointeur constant, en revanche. Peut-être tu veux dire handle, alors, et non handler. Un handle, c'est un identificateur pour un système externe, un espèce de « magic cookie », en somme, qui permet à l'autre système de trouver l'objet, mais qui n'a pas d'itentité pour nous.
Ma question est donc simple : pourquoi ne pas utiliser un pointeur constant ?
Pour permettre à l'autre système de gérer comme il veut. J'ai déjà fait que le handle soit en fait le pointeur, convertit au type voulu. Mais côté utilisateur, ce n'était pas un pointeur ; ce n'était qu'une valeur arbitraire qui permettait l'identification de l'objet. (Et dans un cas, on a bien changé l'implémentation par la suite, et certains des objets se trouvaient alors cachés sur disque. Et le handle, du coup, n'était pas qu'un pointeur.)
J'imagine qu'il doit y avoir des exemples standards.
Sinon, est il *toujours* préférable d'implémenter une classe handler plutot que de renvoyer des pointeurs constants ? Et si oui, pourquoi ?
Une classe HANDLER a un comportement non-trivial. C'est l'observeur dans le modèle observeur. Une classe HANDLE, en revanche... Chez moi, c'est en général un typedef à unsigned int, ou quelque chose du genre. (Je crois que c'est le cas sous Windows, aussi.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
meow wrote:
Si j'ai bien compris l'histoire, un handler est l'émulation d'un
pointeur constant.
Handler, c'est un mot sans signification très précis. On s'en
sert quand on ne trouve pas de meilleur mot pour décrire ce que
fait la classe. C'est un peu comme « Manager » à cet égard :
la différence, c'est qu'en général, on s'attend à ce qu'un
handler réagisse à quelque chose d'extérieur. C'est souvent le
cas aussi des managers, mais les handlers réagissent plus
directement.
Je ne vois pas de rapport avec un pointeur constant, en
revanche. Peut-être tu veux dire handle, alors, et non handler.
Un handle, c'est un identificateur pour un système externe, un
espèce de « magic cookie », en somme, qui permet à l'autre
système de trouver l'objet, mais qui n'a pas d'itentité pour
nous.
Ma question est donc simple : pourquoi ne pas utiliser un
pointeur constant ?
Pour permettre à l'autre système de gérer comme il veut. J'ai
déjà fait que le handle soit en fait le pointeur, convertit au
type voulu. Mais côté utilisateur, ce n'était pas un pointeur ;
ce n'était qu'une valeur arbitraire qui permettait
l'identification de l'objet. (Et dans un cas, on a bien changé
l'implémentation par la suite, et certains des objets se
trouvaient alors cachés sur disque. Et le handle, du coup,
n'était pas qu'un pointeur.)
J'imagine qu'il doit y avoir des exemples standards.
Sinon, est il *toujours* préférable d'implémenter une classe
handler plutot que de renvoyer des pointeurs constants ? Et si
oui, pourquoi ?
Une classe HANDLER a un comportement non-trivial. C'est
l'observeur dans le modèle observeur. Une classe HANDLE, en
revanche... Chez moi, c'est en général un typedef à unsigned
int, ou quelque chose du genre. (Je crois que c'est le cas sous
Windows, aussi.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Si j'ai bien compris l'histoire, un handler est l'émulation d'un pointeur constant.
Handler, c'est un mot sans signification très précis. On s'en sert quand on ne trouve pas de meilleur mot pour décrire ce que fait la classe. C'est un peu comme « Manager » à cet égard : la différence, c'est qu'en général, on s'attend à ce qu'un handler réagisse à quelque chose d'extérieur. C'est souvent le cas aussi des managers, mais les handlers réagissent plus directement.
Je ne vois pas de rapport avec un pointeur constant, en revanche. Peut-être tu veux dire handle, alors, et non handler. Un handle, c'est un identificateur pour un système externe, un espèce de « magic cookie », en somme, qui permet à l'autre système de trouver l'objet, mais qui n'a pas d'itentité pour nous.
Ma question est donc simple : pourquoi ne pas utiliser un pointeur constant ?
Pour permettre à l'autre système de gérer comme il veut. J'ai déjà fait que le handle soit en fait le pointeur, convertit au type voulu. Mais côté utilisateur, ce n'était pas un pointeur ; ce n'était qu'une valeur arbitraire qui permettait l'identification de l'objet. (Et dans un cas, on a bien changé l'implémentation par la suite, et certains des objets se trouvaient alors cachés sur disque. Et le handle, du coup, n'était pas qu'un pointeur.)
J'imagine qu'il doit y avoir des exemples standards.
Sinon, est il *toujours* préférable d'implémenter une classe handler plutot que de renvoyer des pointeurs constants ? Et si oui, pourquoi ?
Une classe HANDLER a un comportement non-trivial. C'est l'observeur dans le modèle observeur. Une classe HANDLE, en revanche... Chez moi, c'est en général un typedef à unsigned int, ou quelque chose du genre. (Je crois que c'est le cas sous Windows, aussi.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
meow
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
Oups, oui, je voulais bien dire 'Handle'.
Et merci pour la réponse, elle est très claire.
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
Dominique Vaufreydaz
Bonjour,
meow wrote:
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne veut pas que tu connaissent le contenu. On te donne une reference (hashcode par exempel) et des fonction pour le manipuler. Ca permet d'augmenter la securite de ceux qui l'utilise.
Ca evite bon nombre de probleme.
Qu'on me corrige/complete si je me trompe. Doms.
Bonjour,
meow wrote:
Oups, oui, je voulais bien dire 'Handle'.
Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est
en general une reference a un objet (systeme sous windows) dont on ne
veut pas que tu connaissent le contenu. On te donne une reference (hashcode
par exempel) et des fonction pour le manipuler. Ca permet d'augmenter la securite
de ceux qui l'utilise.
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne veut pas que tu connaissent le contenu. On te donne une reference (hashcode par exempel) et des fonction pour le manipuler. Ca permet d'augmenter la securite de ceux qui l'utilise.
Ca evite bon nombre de probleme.
Qu'on me corrige/complete si je me trompe. Doms.
kanze
Dominique Vaufreydaz wrote:
meow wrote:
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne veut pas que tu connaissent le contenu. On te donne une reference (hashcode par exempel) et des fonction pour le manipuler. Ca permet d'augmenter la securite de ceux qui l'utilise.
Ca evite bon nombre de probleme.
Qu'on me corrige/complete si je me trompe. Doms.
Pas une correction, mais un complèment. L'importance dans un handle, je crois, c'est l'opacité vis-à-vis de l'utilisateur. Je ne connais pas le Windows moderne, mais dans MS-DOS (et dans les Unix primitifs), le « handle » était une indice dans un tableau système, un entier entre 0 et un nombre positif assez petit. Dans le premier système que j'ai écrit pour le 8086, en revanche, c'était bien une partie de l'adresse, l'offset dans le segment système. Et d'autres solutions sont possibles. L'importance, c'est bien qu'il permet au serveur de rétrouver l'objet en question, et que pour le client, c'est opaque, qu'il n'a pas à savoir si c'est une adresse, une indice ou un hashcode.
On pourrait ajouter que certains handles ont des valeurs singulaires. Donc, par exemple, les file descripteurs de Unix (et dans le temps, les handles de MS-DOS aussi) ont un type int (derrière le typedef, sous Windows), et c'est guaranti que tout handle valide est positif. Du coup, une fonction comme open renvoie -1 comme signal d'erreur. Ce qui nuit un peu à l'opacité -- mieux serait peut-être une valeur constante symbolique -- mais depuis le temps, au moins sous Unix, il existe des programmes qui testent pour < 0, ou pour -1. Sous Windows, c'est apparamment un void*, mais c'est encore (void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur (et les adresses sont allouées au pas de 4, ce qui fait penser qu'il ne s'agit quand même pas des vraies adresses des objets dans le système).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dominique Vaufreydaz wrote:
meow wrote:
Oups, oui, je voulais bien dire 'Handle'.
Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur
static, c'est en general une reference a un objet (systeme
sous windows) dont on ne veut pas que tu connaissent le
contenu. On te donne une reference (hashcode par exempel)
et des fonction pour le manipuler. Ca permet d'augmenter
la securite de ceux qui l'utilise.
Ca evite bon nombre de probleme.
Qu'on me corrige/complete si je me trompe. Doms.
Pas une correction, mais un complèment. L'importance dans un
handle, je crois, c'est l'opacité vis-à-vis de l'utilisateur.
Je ne connais pas le Windows moderne, mais dans MS-DOS (et dans
les Unix primitifs), le « handle » était une indice dans un
tableau système, un entier entre 0 et un nombre positif assez
petit. Dans le premier système que j'ai écrit pour le 8086, en
revanche, c'était bien une partie de l'adresse, l'offset dans le
segment système. Et d'autres solutions sont possibles.
L'importance, c'est bien qu'il permet au serveur de rétrouver
l'objet en question, et que pour le client, c'est opaque, qu'il
n'a pas à savoir si c'est une adresse, une indice ou un
hashcode.
On pourrait ajouter que certains handles ont des valeurs
singulaires. Donc, par exemple, les file descripteurs de Unix
(et dans le temps, les handles de MS-DOS aussi) ont un type int
(derrière le typedef, sous Windows), et c'est guaranti que tout
handle valide est positif. Du coup, une fonction comme open
renvoie -1 comme signal d'erreur. Ce qui nuit un peu à
l'opacité -- mieux serait peut-être une valeur constante
symbolique -- mais depuis le temps, au moins sous Unix, il
existe des programmes qui testent pour < 0, ou pour -1. Sous
Windows, c'est apparamment un void*, mais c'est encore
(void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur (et
les adresses sont allouées au pas de 4, ce qui fait penser qu'il
ne s'agit quand même pas des vraies adresses des objets dans le
système).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oups, oui, je voulais bien dire 'Handle'. Et merci pour la réponse, elle est très claire.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne veut pas que tu connaissent le contenu. On te donne une reference (hashcode par exempel) et des fonction pour le manipuler. Ca permet d'augmenter la securite de ceux qui l'utilise.
Ca evite bon nombre de probleme.
Qu'on me corrige/complete si je me trompe. Doms.
Pas une correction, mais un complèment. L'importance dans un handle, je crois, c'est l'opacité vis-à-vis de l'utilisateur. Je ne connais pas le Windows moderne, mais dans MS-DOS (et dans les Unix primitifs), le « handle » était une indice dans un tableau système, un entier entre 0 et un nombre positif assez petit. Dans le premier système que j'ai écrit pour le 8086, en revanche, c'était bien une partie de l'adresse, l'offset dans le segment système. Et d'autres solutions sont possibles. L'importance, c'est bien qu'il permet au serveur de rétrouver l'objet en question, et que pour le client, c'est opaque, qu'il n'a pas à savoir si c'est une adresse, une indice ou un hashcode.
On pourrait ajouter que certains handles ont des valeurs singulaires. Donc, par exemple, les file descripteurs de Unix (et dans le temps, les handles de MS-DOS aussi) ont un type int (derrière le typedef, sous Windows), et c'est guaranti que tout handle valide est positif. Du coup, une fonction comme open renvoie -1 comme signal d'erreur. Ce qui nuit un peu à l'opacité -- mieux serait peut-être une valeur constante symbolique -- mais depuis le temps, au moins sous Unix, il existe des programmes qui testent pour < 0, ou pour -1. Sous Windows, c'est apparamment un void*, mais c'est encore (void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur (et les adresses sont allouées au pas de 4, ce qui fait penser qu'il ne s'agit quand même pas des vraies adresses des objets dans le système).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne Qu'on me corrige/complete si je me trompe. Doms.
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie), mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
-- Alain
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est
en general une reference a un objet (systeme sous windows) dont on ne
Qu'on me corrige/complete si je me trompe. Doms.
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie),
mais cela peut aussi être une référence à un objet. Par exemple le
handle de fenêtre.
un handle (tres utilisé sous windows) n'est pas un poiteur static, c'est en general une reference a un objet (systeme sous windows) dont on ne Qu'on me corrige/complete si je me trompe. Doms.
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie), mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
-- Alain
Alain Gaillard
Sous Windows, c'est apparamment un void*,
Plus qu'apparemment, c'est exactement ça.
mais c'est encore (void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur
Cependant tu te trompes, sans doute parce que tu pars du principe que Windows est homogène et cohérent avec lui même. Mais Windows n'est pas Unix. Ainsi CreateFileEx va retourner -1 (INVALID_HANDLE_VALUE) en cas d'erreur, mais CreateWindowEx va retourner 0 en cas d'erreur. Dans ce dernier cas le handle est un identificateur d'objet. Alors que GlobalAlloc par exemple est effectivement un pointeur sur la mémoire allouée. Bref c'est le bordel :-)
(et les adresses sont allouées au pas de 4, ce qui fait penser qu'il ne s'agit quand même pas des vraies adresses des objets dans le système).
Tantôt oui tantôt non donc. Mais je ne comprends pas bien ce que tu as voulu dire par "allouées au pas de 4".
-- Alain
Sous
Windows, c'est apparamment un void*,
Plus qu'apparemment, c'est exactement ça.
mais c'est encore
(void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur
Cependant tu te trompes, sans doute parce que tu pars du principe que
Windows est homogène et cohérent avec lui même. Mais Windows n'est pas Unix.
Ainsi CreateFileEx va retourner -1 (INVALID_HANDLE_VALUE) en cas
d'erreur, mais CreateWindowEx va retourner 0 en cas d'erreur. Dans ce
dernier cas le handle est un identificateur d'objet. Alors que
GlobalAlloc par exemple est effectivement un pointeur sur la mémoire
allouée.
Bref c'est le bordel :-)
(et
les adresses sont allouées au pas de 4, ce qui fait penser qu'il
ne s'agit quand même pas des vraies adresses des objets dans le
système).
Tantôt oui tantôt non donc.
Mais je ne comprends pas bien ce que tu as voulu dire par "allouées au
pas de 4".
mais c'est encore (void*)(-1) (plutôt que NULL) qui sert d'indicateur d'erreur
Cependant tu te trompes, sans doute parce que tu pars du principe que Windows est homogène et cohérent avec lui même. Mais Windows n'est pas Unix. Ainsi CreateFileEx va retourner -1 (INVALID_HANDLE_VALUE) en cas d'erreur, mais CreateWindowEx va retourner 0 en cas d'erreur. Dans ce dernier cas le handle est un identificateur d'objet. Alors que GlobalAlloc par exemple est effectivement un pointeur sur la mémoire allouée. Bref c'est le bordel :-)
(et les adresses sont allouées au pas de 4, ce qui fait penser qu'il ne s'agit quand même pas des vraies adresses des objets dans le système).
Tantôt oui tantôt non donc. Mais je ne comprends pas bien ce que tu as voulu dire par "allouées au pas de 4".
-- Alain
Dominique Vaufreydaz
Bonjour,
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie),
32 bits quoi, ca serait un char[4] que ca serait pareil. C'est juste de l'"offuscation" de memoire.
mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket ou de fichier n'a aucun rapport avec son descripteur que l'on peut obtenir avec une fonction.
Doms.
Bonjour,
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie),
32 bits quoi, ca serait un char[4] que ca serait pareil. C'est juste
de l'"offuscation" de memoire.
mais cela peut aussi être une référence à un objet. Par exemple le
handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket
ou de fichier n'a aucun rapport avec son descripteur que
l'on peut obtenir avec une fonction.
Sous Windows un HANDLE est à la base un pointeur void* (je simplifie),
32 bits quoi, ca serait un char[4] que ca serait pareil. C'est juste de l'"offuscation" de memoire.
mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket ou de fichier n'a aucun rapport avec son descripteur que l'on peut obtenir avec une fonction.
Doms.
Alain Gaillard
C'est juste de l'"offuscation" de memoire.
On peut le formuler comme ça :-)
mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket ou de fichier n'a aucun rapport avec son descripteur que l'on peut obtenir avec une fonction.
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
-- Alain
C'est juste
de l'"offuscation" de memoire.
On peut le formuler comme ça :-)
mais cela peut aussi être une référence à un objet. Par exemple le
handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket
ou de fichier n'a aucun rapport avec son descripteur que
l'on peut obtenir avec une fonction.
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais
cela ne constitue pas une excuse pour autant.
mais cela peut aussi être une référence à un objet. Par exemple le handle de fenêtre.
Exact, toujours pour l'opacite. D'ailleurs un handle de socket ou de fichier n'a aucun rapport avec son descripteur que l'on peut obtenir avec une fonction.
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
-- Alain
Dominique Vaufreydaz
Bonjour,
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres structures/tableaux de données, je comprends aisement que le systeme cache un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi pour le truc que je developpe actuellement mais bon...
Doms.
Bonjour,
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais
cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres
structures/tableaux de données, je comprends aisement que le systeme cache
un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi
pour le truc que je developpe actuellement mais bon...
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres structures/tableaux de données, je comprends aisement que le systeme cache un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi pour le truc que je developpe actuellement mais bon...
Doms.
Alain Gaillard
Bonjour,
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres structures/tableaux de données, je comprends aisement que le systeme cache un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi pour le truc que je developpe actuellement mais bon...
Doms.
Oui, je faisais allusion au manque d'homogénité que le l'on rencontre avec les handle.
-- Alain
Bonjour,
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais
cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres
structures/tableaux de données, je comprends aisement que le systeme cache
un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi
pour le truc que je developpe actuellement mais bon...
Doms.
Oui, je faisais allusion au manque d'homogénité que le l'on rencontre
avec les handle.
Opacité toujours :-) Je pense qu'il y a des raisons historiques mais cela ne constitue pas une excuse pour autant.
Mouai, quand on voit ce que font les utilisateurs de leurs propres structures/tableaux de données, je comprends aisement que le systeme cache un maximum de chose. Si j'avais eu le temps, je l'aurais fait ainsi pour le truc que je developpe actuellement mais bon...
Doms.
Oui, je faisais allusion au manque d'homogénité que le l'on rencontre avec les handle.
