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 ?
En fait, tout l'intérêt, c'est que pour l'utilisateur, c'est un handle (ou plutôt, un HANDLE).
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.
Ben, j'avoue que je n'ai fait qu'un essai rapide. Disons que CreateFile renvoie (void*)(-1) quand on lui démande de ne pas créer le fichier, et qu'il n'est pas là.
En passant, je le trouve plutôt cool qu'un des paramètres de CreateFile peut servir de lui dire de ne pas créer le fichier s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté la même école de nommage que celui qui a créé std::remove. Voire même celui de Unix, où creat [sic] ne crée pas forcément un nouveau fichier -- alors qu'avec le paramètre qu'il faut, open le fait, et échoue si le fichier existe déjà. Alors, tout le monde a bien compris : sous Windows, on utilise CreateFile pour ouvrir un fichier, et échoué si le fichier n'exite pas, tandis que sous Unix, on utilise open, plutôt que creat [sic] quand on veux être sûr de créer un fichier, plutôt que de se servir d'un qui existe déjà.
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 :-)
Ça ressemble donc à Unix:-).
(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".
Encore, c'était juste un petit essai : j'ai appelé CreateFile sur un tas de fichiers qui existaient, j'ai sortie la valeur de rétour chaque fois, et j'ai trié sur cette valeur. Pour la plupart, l'intervale entre les valeurs était 4. Ce qui me fait penser que le void* ne contient pas un pointeur à des données réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert en seulement quatre octets.
Mais le but n'était pas tellement de dire que Windows fait comme ceci ou celà. Pour ça, il me faudrait le code source de Windows, et encore. Le but, c'était juste pour donnée l'idée qu'on ne sait pas exactement se tient derrière quelque chose que le système a choisi d'appeler HANDLE. Même si on croire connaître le type.
-- 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 wrote:
Sous
Windows, c'est apparamment un void*,
Plus qu'apparemment, c'est exactement ça.
Dans toutes les versions, depuis toujours ? :-)
En fait, tout l'intérêt, c'est que pour l'utilisateur, c'est un
handle (ou plutôt, un HANDLE).
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.
Ben, j'avoue que je n'ai fait qu'un essai rapide. Disons que
CreateFile renvoie (void*)(-1) quand on lui démande de ne pas
créer le fichier, et qu'il n'est pas là.
En passant, je le trouve plutôt cool qu'un des paramètres de
CreateFile peut servir de lui dire de ne pas créer le fichier
s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté
la même école de nommage que celui qui a créé std::remove. Voire
même celui de Unix, où creat [sic] ne crée pas forcément un
nouveau fichier -- alors qu'avec le paramètre qu'il faut, open
le fait, et échoue si le fichier existe déjà. Alors, tout le
monde a bien compris : sous Windows, on utilise CreateFile pour
ouvrir un fichier, et échoué si le fichier n'exite pas, tandis
que sous Unix, on utilise open, plutôt que creat [sic] quand on
veux être sûr de créer un fichier, plutôt que de se servir d'un
qui existe déjà.
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 :-)
Ça ressemble donc à Unix:-).
(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".
Encore, c'était juste un petit essai : j'ai appelé CreateFile
sur un tas de fichiers qui existaient, j'ai sortie la valeur de
rétour chaque fois, et j'ai trié sur cette valeur. Pour la
plupart, l'intervale entre les valeurs était 4. Ce qui me fait
penser que le void* ne contient pas un pointeur à des données
réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert
en seulement quatre octets.
Mais le but n'était pas tellement de dire que Windows fait comme
ceci ou celà. Pour ça, il me faudrait le code source de Windows,
et encore. Le but, c'était juste pour donnée l'idée qu'on ne
sait pas exactement se tient derrière quelque chose que le
système a choisi d'appeler HANDLE. Même si on croire connaître
le type.
--
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
En fait, tout l'intérêt, c'est que pour l'utilisateur, c'est un handle (ou plutôt, un HANDLE).
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.
Ben, j'avoue que je n'ai fait qu'un essai rapide. Disons que CreateFile renvoie (void*)(-1) quand on lui démande de ne pas créer le fichier, et qu'il n'est pas là.
En passant, je le trouve plutôt cool qu'un des paramètres de CreateFile peut servir de lui dire de ne pas créer le fichier s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté la même école de nommage que celui qui a créé std::remove. Voire même celui de Unix, où creat [sic] ne crée pas forcément un nouveau fichier -- alors qu'avec le paramètre qu'il faut, open le fait, et échoue si le fichier existe déjà. Alors, tout le monde a bien compris : sous Windows, on utilise CreateFile pour ouvrir un fichier, et échoué si le fichier n'exite pas, tandis que sous Unix, on utilise open, plutôt que creat [sic] quand on veux être sûr de créer un fichier, plutôt que de se servir d'un qui existe déjà.
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 :-)
Ça ressemble donc à Unix:-).
(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".
Encore, c'était juste un petit essai : j'ai appelé CreateFile sur un tas de fichiers qui existaient, j'ai sortie la valeur de rétour chaque fois, et j'ai trié sur cette valeur. Pour la plupart, l'intervale entre les valeurs était 4. Ce qui me fait penser que le void* ne contient pas un pointeur à des données réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert en seulement quatre octets.
Mais le but n'était pas tellement de dire que Windows fait comme ceci ou celà. Pour ça, il me faudrait le code source de Windows, et encore. Le but, c'était juste pour donnée l'idée qu'on ne sait pas exactement se tient derrière quelque chose que le système a choisi d'appeler HANDLE. Même si on croire connaître le type.
-- 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
Dans toutes les versions, depuis toujours ? :-)
Une fois n'est pas coutume. Oui. Enfin il me semble bieb. Même en 16 bits c'était déjà si je me souviens bien.
En passant, je le trouve plutôt cool qu'un des paramètres de CreateFile peut servir de lui dire de ne pas créer le fichier s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté la même école de nommage que celui qui a créé std::remove. Voire même celui de Unix, où creat [sic] ne crée pas forcément un nouveau fichier -- alors qu'avec le paramètre qu'il faut, open le fait, et échoue si le fichier existe déjà. Alors, tout le monde a bien compris : sous Windows, on utilise CreateFile pour ouvrir un fichier, et échoué si le fichier n'exite pas, tandis que sous Unix, on utilise open, plutôt que creat [sic] quand on veux être sûr de créer un fichier, plutôt que de se servir d'un qui existe déjà.
Tout n'est pas à jeter sous Windows :-)
Ça ressemble donc à Unix:-).
LOL
Encore, c'était juste un petit essai : j'ai appelé CreateFile sur un tas de fichiers qui existaient, j'ai sortie la valeur de rétour chaque fois, et j'ai trié sur cette valeur. Pour la plupart, l'intervale entre les valeurs était 4.
Ah d'accord.
Ce qui me fait penser que le void* ne contient pas un pointeur à des données réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert en seulement quatre octets.
En effet pour un appel à CreateFile. En revanche pour un appel à GlobalAlloc par exemple, le HANDLE ets bien un pointeur sur la zone mémoire allouée.
Le but, c'était juste pour donnée l'idée qu'on ne sait pas exactement se tient derrière quelque chose que le système a choisi d'appeler HANDLE. Même si on croire connaître le type.
En effet.
-- Alain
Dans toutes les versions, depuis toujours ? :-)
Une fois n'est pas coutume. Oui. Enfin il me semble bieb. Même en 16
bits c'était déjà si je me souviens bien.
En passant, je le trouve plutôt cool qu'un des paramètres de
CreateFile peut servir de lui dire de ne pas créer le fichier
s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté
la même école de nommage que celui qui a créé std::remove. Voire
même celui de Unix, où creat [sic] ne crée pas forcément un
nouveau fichier -- alors qu'avec le paramètre qu'il faut, open
le fait, et échoue si le fichier existe déjà. Alors, tout le
monde a bien compris : sous Windows, on utilise CreateFile pour
ouvrir un fichier, et échoué si le fichier n'exite pas, tandis
que sous Unix, on utilise open, plutôt que creat [sic] quand on
veux être sûr de créer un fichier, plutôt que de se servir d'un
qui existe déjà.
Tout n'est pas à jeter sous Windows :-)
Ça ressemble donc à Unix:-).
LOL
Encore, c'était juste un petit essai : j'ai appelé CreateFile
sur un tas de fichiers qui existaient, j'ai sortie la valeur de
rétour chaque fois, et j'ai trié sur cette valeur. Pour la
plupart, l'intervale entre les valeurs était 4.
Ah d'accord.
Ce qui me fait
penser que le void* ne contient pas un pointeur à des données
réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert
en seulement quatre octets.
En effet pour un appel à CreateFile.
En revanche pour un appel à GlobalAlloc par exemple, le HANDLE ets bien
un pointeur sur la zone mémoire allouée.
Le but, c'était juste pour donnée l'idée qu'on ne
sait pas exactement se tient derrière quelque chose que le
système a choisi d'appeler HANDLE. Même si on croire connaître
le type.
Une fois n'est pas coutume. Oui. Enfin il me semble bieb. Même en 16 bits c'était déjà si je me souviens bien.
En passant, je le trouve plutôt cool qu'un des paramètres de CreateFile peut servir de lui dire de ne pas créer le fichier s'il n'existe pas déjà. On dirait que les auteurs ont fréquenté la même école de nommage que celui qui a créé std::remove. Voire même celui de Unix, où creat [sic] ne crée pas forcément un nouveau fichier -- alors qu'avec le paramètre qu'il faut, open le fait, et échoue si le fichier existe déjà. Alors, tout le monde a bien compris : sous Windows, on utilise CreateFile pour ouvrir un fichier, et échoué si le fichier n'exite pas, tandis que sous Unix, on utilise open, plutôt que creat [sic] quand on veux être sûr de créer un fichier, plutôt que de se servir d'un qui existe déjà.
Tout n'est pas à jeter sous Windows :-)
Ça ressemble donc à Unix:-).
LOL
Encore, c'était juste un petit essai : j'ai appelé CreateFile sur un tas de fichiers qui existaient, j'ai sortie la valeur de rétour chaque fois, et j'ai trié sur cette valeur. Pour la plupart, l'intervale entre les valeurs était 4.
Ah d'accord.
Ce qui me fait penser que le void* ne contient pas un pointeur à des données réeles ; je ne crois pas qu'on puisse décrire un fichier ouvert en seulement quatre octets.
En effet pour un appel à CreateFile. En revanche pour un appel à GlobalAlloc par exemple, le HANDLE ets bien un pointeur sur la zone mémoire allouée.
Le but, c'était juste pour donnée l'idée qu'on ne sait pas exactement se tient derrière quelque chose que le système a choisi d'appeler HANDLE. Même si on croire connaître le type.
