lib win32 C++, bibliotheques disponibles

"AMcD®" <arnold.mcdonald@free.fr> wrote in message
news:41a6405a$0$19229$636a15ce@news.free.fr...

Vincent Burel wrote:

> et Concrètement c'est de la
> programmation objet, architecture objet...

Heu, j'ai pas cru voir des surcharges,

et le sous classement c'est quoi !? c'est pas une surcharge des fois ? Et
quand tu code dans de la callback, tu serais pas en train de surcharger
sévèrement ton object des fois ! ? :-)

du polymorphisme,

ho ben là c'est n'importe quoi, tu te rend compte que tout ce qui s'affiche
à l'écran sous Windows se fait par des CreateWindow. Si ca c'est pas du
polymorphisme alors regarde l'objet HDC qui te permet de déssiner aussi bien
sur un écran que sur une imprimante, dans une mode comme dans un autre...
C'est bien simple le polymorphisme c'est le concept de base d'un O/S
généraliste un peu évoluer... comment définir la notion de drivers sans
l'idée de polymorphisme !?

de l'héritage, etc.

tu ose dire ca avec tout ce qui hérite de l'object HWND !? :-) Mécréant !
:-)

VB

Aurelien REGAT-BARREL wrote:

Petit apperçu de mon brouillon d'article :
- les fenêtres se parlent via des messages, or c'est ce que le
théorie objet définit (dialogue entre objets via messages)
contrairement aux langages genre C++ où les objets s'appelent
directement - les fenêtres c'est des objets, et on a bien des classes
d'objets qui sont les classes de fenêtres

Windows utilise les messages à cause qu'il est préemptif, je doute qu'il y
ait là grand chose à voir avec les objets...

- on manipule les objets via des handle (design pattern bridge) : ils
permettent l'encapsulation des données et donc l'abstraction, ce qui
est la base de la conception objet.

C'est un peu tiré par les cheveux ça quand même non ?

- WM_CREATE et WM_DESTROY peuvent être vus commes les constructeurs /
destructeurs des objets fenêtres

Oui mais, est ce que ce modèle est présent partout ? As-tu toujours cette
"paire" de messages ?

- les fenêtres supportent l'héritage (via le subclassing) dans un but
de spécialisation (BUTTON, EDIT, ...). Pour autant ce sont toujours
des fenêtres (relation EST UN => qui caractérise l'héritage)

Houla. Toujours tiré par les tifs.

- on peut imaginer l'héritage multiple en chainant 2 WndProc, mais
j'ai jamais croisé cette utilisation

Détaille.

- j'hésite à considérer le super-classing comme un héritage privé =>
composition

Erf.

A partir de là accrochez vous :

- la WndProc sert à redéfinir des messages de la classe de base
(matérialisée par DefWindowProc) ainsi qu'a ajouter de nouveau
messages propres à la classe. Du fait qu'elle supplante le traitement
par défaut des messages de fenêtre, et ce alors que via son HWND on
la considère comme une fenêtre de base, on peut considérer que la
WndProc agit comme la vtable d'une classe C++ et donc que les
messages déclenchent l'appel de fonctions virtuelles via la WndProc...

Matt Pietrek, Jeffrey Richter, Andrew Schulmann et Ralph Lipe, priez pour
lui, il ne sait pas ce qu'il fait :-).

- j'hésite à caser la méta-programmation avec RegisterClass qui
permet de créer des classes de fenêtres...

Oui. Hésite. Ou alors, tant que tu y es, parle de l'auto-modification de
code via writeprocessmemory(), là t'aura ton full polymorphisme.

Voilà en gros ce que donnera mon article (si je le finis)... Votre
opinion est la bienvenue :-)

Mon opinion est qu'à force de tirer sur les cheveux on fini chauve...
(humour force 5)

--
AMcD®

http://arnold.mcdonald.free.fr/

Aurelien REGAT-BARREL a écrit :

Pour le tordu je faisais référence à la fin de mon
autre post : vtable, Delegate, ...

A mon humble avis, si tu veux mettre en avant une
certaine manière de faire de l'OO avec Win32, ce n'est
peut être pas utile d'essayer de trouver des équivalents
à chaque terme. Il y a des classes et des méthodes, des
objets et leurs données. Sauf à appeler directement
les WindowProcs, toutes les méthodes sont virtuelles.
Ca suffit, et il n'y a pas besoin d'aller chercher
quelques ressemblances entre une vtable et un switch
de WindowProc.

Par contre, le point passionnant dans cette histoire
(à mon humble avis) c'est PostMessage. Tu peux faire
de l'objet avec invocation asynchrone... Ca conduit
à une autre manière de programmer (et à une nouvelle
manière de faire des programmes buggés :-) )

--
<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"

> Par contre, le point passionnant dans cette histoire
(à mon humble avis) c'est PostMessage. Tu peux faire
de l'objet avec invocation asynchrone... Ca conduit
à une autre manière de programmer (et à une nouvelle
manière de faire des programmes buggés :-) )

C'est ce que j'hésite à qualifier de Delegate... C'est pas vraiment
nouveaux, c'est le principe des signaux/slots en Qt, et effectivement des
bugs vicieux :-)
SIGNAL( TuVasEtreDetruit ) suivit de delete, sauf que le message est traité
plus tard, et l'objet est déjà détruit, d'où des parades louches comme
deleteLater()...

--
Aurélien REGAT-BARREL

> Windows utilise les messages à cause qu'il est préemptif, je doute qu'il y
ait là grand chose à voir avec les objets...

Je vois pas trop le rapport.

- on manipule les objets via des handle (design pattern bridge) : ils
permettent l'encapsulation des données et donc l'abstraction, ce qui
est la base de la conception objet.

C'est un peu tiré par les cheveux ça quand même non ?

Franchement je pense pas. C'est même expliqué dans la MSDN/Win32.hlp. En
empêchant (enfin décourageant fortement) des bidouilleurs comme toi
d'accéder à la structure interne de ses objets, Win32 peut les faire évoluer
sans péter la compatibilité binaire avec du vieux code.
C'est LE but du pattern bridge "découpler une abstraction de son
implémentation, afin que les deux puissent évoluer séparément ". Win32 y
greffe dessus le mécanisme de sécurité en plus.
C'est ce qui fait que Win32 est qualifié par certains de OO. Tenenbaum le
mentionne dans son dernier bouquin sur les OS où il parle de Win2K. Il
rajoute que c'est pas vraiment OO car y'a pas l'héritage.

- WM_CREATE et WM_DESTROY peuvent être vus commes les constructeurs /
destructeurs des objets fenêtres

Oui mais, est ce que ce modèle est présent partout ? As-tu toujours cette
"paire" de messages ?

Ben tu devrais mieux le savoir que moi. Sur les fenêtres de base oui.
Maintenant des trucs comme les dialog filtrent le bazard (=> WM_INITDIALOG),
mais n'empêchent qu'elles doivent les recevoir.
Tu reçois pas WM_DESTROY si WM_CREATE a échoué, ce qui est le même
comportement qu'avec un constrcuteur C++ (destructeur pas appelé si le
constructeur échoue).

- les fenêtres supportent l'héritage (via le subclassing) dans un but
de spécialisation (BUTTON, EDIT, ...). Pour autant ce sont toujours
des fenêtres (relation EST UN => qui caractérise l'héritage)

Houla. Toujours tiré par les tifs.

Là encore ça me surprend que tu doutes. Ton bouton EST UNE fenêtre =>
héritage. Certains messages sont traités de manière perso => surcharge des
"méthodes" de la classe.

- on peut imaginer l'héritage multiple en chainant 2 WndProc, mais
j'ai jamais croisé cette utilisation

Détaille.

Un truc genre un controle EDIT cliquable, ou plutot un bouton avec le texte
modifiable. Tu crées ta classe EDITBUTTON en filant comme WndProc une
WndProc qui appelle celle de EDIT puis celle de BUTTON. Sauf que ça doit pas
être évident de déterminer quoi renvoyer / qui appeler. C'était une
imagination ;-)

A partir de là accrochez vous :

[...]

Matt Pietrek, Jeffrey Richter, Andrew Schulmann et Ralph Lipe, priez pour
lui, il ne sait pas ce qu'il fait :-).

J'avais prévenu :-)

- j'hésite à caser la méta-programmation avec RegisterClass qui
permet de créer des classes de fenêtres...

Oui. Hésite. Ou alors, tant que tu y es, parle de l'auto-modification de
code via writeprocessmemory(), là t'aura ton full polymorphisme.

Bien vu! ;-)
Y'a plusieurs types de polymorphismes, on doit pas parler du même :-O

Voilà en gros ce que donnera mon article (si je le finis)... Votre
opinion est la bienvenue :-)

Mon opinion est qu'à force de tirer sur les cheveux on fini chauve...

On dit aussi capillotracté.

Note que je me positionne tout là haut dans le monde des concepts. Vu de là,
on peut considérer DeleteObject ainsi:

class HGdiObj;

void DeleteObject( HGdiObj );

class HPen : HGdiObj {};
class HBrush : HGdiObj {};

HPen pen;
DeleteObject( pen ); // polymorphisme !

Si t'es trop bas niveau tu considères HGdiObj comme une union des 2
précédents, + un champ Id (ce qui est effectivement + proche de la réalité).
Mais ça, c'est comment c'est implémenté. Moi je m'intéresse à comment c'est
designé. Si Win32 avait été écrit en C++, on aurait sûrement eu un truc de
ce genre.

Bah sans déconner, c'est un point de vue intéressant non ?


--
Aurélien REGAT-BARREL

Manuel Leclerc wrote:

Après, voir de l'OO dans le fait qu'il y a une API CloseHandle,
je trouve ça sérieusement tiré par les cheveux.

Ah bon, et pourquoi çà? CloseHandle est une fonction (une eu une seule
interface) qui fait des choses différentes (CloseHandle sur un fichier ou un
mutex, ca n'a rien à voir) selon le type réel d'un de ses paramètres (le
type de l'objet derrière le handle) :
Pour moi, c'est la défintion formelle du polymorphisme de type (subtyping
polymorphism, comment traduire çà en français?). La seule nuance, c'est que
nous nous plaçons du point de vue de l'utilisateur d'uns système polymorphe,
pas de celui qui l'écrit.

Sinon, pourquoi est-ce que vous tenez tous absolument à ne prendre vos
exemple que dans le système de fenêtrage? Ce n'est qu'une toute petite
partie de l'API Win32!

Arnaud

> Sinon, pourquoi est-ce que vous tenez tous absolument à ne prendre vos
exemple que dans le système de fenêtrage? Ce n'est qu'une toute petite
partie de l'API Win32!

Ben en dehors des classes de fenêtres tu connais beaucoup d'objets que tu
peux spécialiser par héritage ?

--
Aurélien REGAT-BARREL

Arnaud Debaene a écrit :

Sinon, pourquoi est-ce que vous tenez tous absolument à ne prendre vos
exemple que dans le système de fenêtrage? Ce n'est qu'une toute petite
partie de l'API Win32!

Arnaud

En utilisant les sockets de win32, je n est pas remarqué d utilisation
objet des fonctions, mais bien des appels avec pointeurs ou handle à la
mode C. On peut parfaitement faire des liens entre outils objet (passage
d objet, constructeur, masquage de données ...) avec du code non objet
utilisant ces concepts , mais cela devient à la charge de programmeur et
non une facilité automatique.

--
Dom

> En utilisant les sockets de win32, je n est pas remarqué d utilisation
objet des fonctions, mais bien des appels avec pointeurs ou handle à la
mode C. On peut parfaitement faire des liens entre outils objet (passage
d objet, constructeur, masquage de données ...) avec du code non objet
utilisant ces concepts , mais cela devient à la charge de programmeur et
non une facilité automatique.

Oui, parce que c'est mappé sur l'API Berkeley. Ca fait un peu tâche
d'ailleurs, tu noteras que c'est une de seules API de Win32 à avoir des noms
minuscules, à ne pas utiliser de handle, etc...
Encore que winsock2 apporte WPUCreateSocketHandle qui te renvoie un handle
utilisable avec ReadFile / WriteFile (le kernel se charge de rerouter vers
les bonnes fonctions, on peut donc bien considérer dans ce cas que le handle
de socket est un handle de fichier et que les méthodes read et write sont
supplantées => héritage).


--
Aurélien REGAT-BARREL

> On n'est pas tordu du tout, c'est assez évident si tu veux
bien examiner les APIs en question et l'ensemble qu'elles
forment. Il faut quand même remarquer que cette mécanique
est en place depuis plus d'une quinzaine d'année au moins,
ne t'imagines pas avoir fait là une grande découverte :-)

Au fait, aurais-tu des liens vers des articles ayant cette approche de Win32
? Je m'étonne de ne jamais en avoir croisé (c'est ce qui me motive à en
écrire un).

--
Aurélien REGAT-BARREL