j'ai besoin d'avis...

j'en pense sandwich au fraises
 
(tu veux pas un peu developper ?)

clakance de la question.
 
alors vais apporter ma contribution : en win32, un handle c'est un void*, alors ce que j'en pense...
 
si ca réponds pas a la question, ben précise un peu plus les choses...

Le cancer:
pour ou contre ?
 
LeGreg

y'a t'il une mort apres la vie ?

Pour le salon quel papier peint?
 
Heu si non une question plus précise ce serait bien

can you handle it ?

Does you or not ?

 
quel tomik de qualitay

Ca doit sûrement être cool?

faut-il tuer son chef de projet ou non?

 
  C'est le patron qu'il faut tuer?  

fodger >> tu es prié de t'expliquer un peu plus, sinon je ferme ton topic ce soir.
 
les autres >> pas la peine de polluer avant de savoir exactement de quoi il retourne...

merci pour la richesse des commentaires ...
 
Et bien pour développer un peu plus :  
admettons que nous ayons beaucoup de grosses structures...
 
Pour vous y'a t'il un intérêt à utiliser les handle pour travailler avec (genre 1 fonction avec un handle pour variable récupérer le(s) champ(s) qui nous interesse), plutôt que de déclarer directement les variables sur ces mêmes structures?  
 
Je me suis peut être mal exprimé:D...

Ouf, j'ai cru un instant que tu pensais être clair!

 
  Et en français ça donne?

 
 
Et tes handles, c'est pas des variables peut-être ?

 
mmhhh voidrait tu dire passer un pointeur sur une struct plutot que de passer tout les membres de la struct ???
 
 
dans ce cas oui c mieux, c plus facile pour appeler la fonction , puis c uniquement 4bytes a passer aussi  

jsens que jai encore raconter une connerie

 
En fait ça dépend de l'architecture de la machine si on veut être pointilleux   , mais c généralement moin gros qu'une structure

Bon, je vais essayer de formuler une opinion...
L'unique intérêt que je peut voir au Handle est de pouvoir manipuler des données sans rien savoir de ce qu'est réellement ce Handle (pointeur, identifiant...). L'utilisateur ne peut normalement pas utiliser ce Handle en dehors des fonctions que tu as défini. Je vois ça plus comme un moyen de protection qu'autre chose.

 
oué dans ce genre là:p... donc pour toi ça vaut le coup... parce que j'ai tendance à penser que parfois ça compliquer très rapidement les choses, et occuper plus de place mémoire...

 
là tout à fait d'accord...

 
par exemple pour netbios (bon je c complement depassé et plus personne nutilise ca) il ya une 20aine de parametres a passer :
 
on remplit la structure puis on la passe a la fonction tout simplement
 
jvois mal : Netbios (param1 ,param2, param3 , ... , param 23,..)

 
La structure directement, pas un handle?

 
un pointeur sur struct

 
protection contre quoi?

[img]

 
Protection contre une mauvaise utilisation.
 
Par exemple, si je crée une bibliothèque permettant de gérer des images. J'imagine que je stocke mes images dans une structure avec la largeur, la hauteur, le nombre de bits par pixel et enfin un pointeur vers une zone mémoire contenant l'image brute. Je propose également des fonctions permettant de modifier l'image (rotation, recadrage...). Pour que ces fonctions puissent fonctionner, il faut qu'elles sachent sur quelle image elles doivent agir.
Donc soit je laisse tout transparent et je demande à l'utilisateur de me passer un pointeur vers la structure image, soit je demande handle et ma fonction pourra aller chercher ces informations elle-même.
Le problème avec la première solution est que l'utilisateur de ma bibliothèque a accès à toutes les informations sur mon image. Si il souhaite modifier la largeur de l'image, il peut le faire et donc faire planter toutes mes fonctions après. Par contre, avec un handle, la façon dont sont gérées les images reste opaque. Il ne peut donc pas modifier ma structure et tout faire planter.

Bref, ça s'appelle l'encapsulation. Un des concepts fondamentaux de la programmation objet... et un des moyens les plus puissants qu'on ait trouvé pour réduire statistiquement le nombre de bugs d'un programme.

ben non, les handles, c'est des types opaques, on ne sait pas ce que c'est, on sait juste à quoi ça sert, ce qui est quand même différent je pense

 
Merci, c'est effectivement de l'encapsulation, je ne savais pas que cela existait de maniere aussi "evoluee" en C.

 
un des moyens les plus puissants pour réduire les bug se sont plutôt suivre des méthodes de travail telle qu'on en retrouve dans des normes ieee, rup, iso...

Non c'est naze. On utilise ça uniquement si on veut pas que le dev puisse toucher aux structures ou si il est impossible de prendre un pointeur dessus (style la structure est en espace noyau, comme dans le cas des fichiers, ou quand elle est physiquement sur une autre machine).
 
En plus ça rajoute des indirections inutiles que le compilo ne saura pas virer. Et ça n'apporte strictement rien à part de la complexité.

Les handles permettent d'obliger le programmeur à passer par l'interface de ton choix et lui interdisent de procéder autrement (routines maisons...). 2 avantages principaux. Le premier a été dit : la sécurité. En empêchant le programmeur de modifier directement les objets on est assuré qu'ils sont toujours valides. Qui plus est on peut contrôler leur utilisation (droits...).
Le 2° avantage est l'évolutivité : le code client n'est pas lié à une implémentation particulière des ojets manipulés. Tu peux alors en interne totalement modifier tes structures. Il te suffit de conserver la même interface pour rester compatible avec le code existant.
http://coding.bug.free.fr/win/hobj.htm
 
PS : c'est pas lié au langage C

On s'en fout de ça, on met des pointeurs, on documente pas la structure et on met des accesseurs et on la la même chose en version plus rapide.

AMHA tu décris une manière d'implémenter le mécanisme à partir de pointeurs. Il me semble que Win9x calcules les handles à partir des pointeurs "XORé" avec un obfuscator.
Le problème du undocumented c'est que des bidouilleur vont le documenter et les routines maisons vont voir le jour.

ça on s'en fout, si c'est dans le même espace mémoire, c'est de toutes façons accessible, obfuscation à la con ou pas, à coup de debugger, c'est vite réglé.  
 
L'unique moyen de protéger une structure est de la sortir de l'espace mémoire du process (ce que fait le noyau par ex, en gardant les données sensibles associées au process dans son espace) auquel cas, une référence abstraite est l'unique moyen de savoir de quoi on parle dans les fonctions.

Le problème, c'est qu'en C, pour pouvoir définir le pointeur sur structure, tu es obligé de définir la structure préalablement. Donc comme la définition du type pointeur est public, la définition de la structure est nécessairement publique, dans le .h aussi.
 
Autre solution, tu écris 2 .h, un public et un privé, le .h public définit une structure bidon -- sauf s'il est inclus par le .h privé -- et le .h privé définit la structure véritable. Du coup, l'utilisateur manipule quelque chose qui est en fait un pointeur sur la véritable structure de données, mais cette dernière lui est masquée. Donc pas d'indirection.
 
Mais par définition, ce que manipule l'utilisateur dans ce cas, ça s'appelle quand même un handle.  
 

 
Non, ou alors j'ai mal compris.
Une déclaration suffit, la définition vient dans le .c.
C'est même une encapsulation plus forte qu'en C++