lib win32 C++, bibliotheques disponibles

Aurélien REGAT-BARREL wrote:

J'ai quand même envie de pinailler, surtout que je rédige un petit
article là dessus, ça va me permettre d'avoir votre avis. Win32 est
en C, certes, mais cela ne l'empêche pas d'être orienté objet.

En interne, c'est "conceptuellement" objet (je vais me faire tuer par les
puristes), t'as des blocs, tokens, privilèges, etc. Mais bon, c'est codé en
C. Architecturellement pensé objet si tu veux, mais concrètement pas objet
au final...

retrouve beaucoups de concepts objets, on peut même être plus proche
de la théorie objet qu'avec des langages comme C++ ou même Java/C#.
Classes, constructeurs/destructeurs, héritage, polymorphisme,
fonctions virtuelles, ... sont des notions que l'on peut identifier,
à faible dose cela dit.

Heu, il n'y a rien de ça dans Win32. Tu confonds avec MFC non ? Bon, c'est
vrai Qu'un CreatePen() suivi d'un DeleteObject(), ça fait furieusement
penser construteur/destructeur...

OWL c'est mort depuis belle lurette non ? VCL a pris le pas il me
semble (elle même est morte aussi non ?).

Ben ça dépend avec quoi tu codes :-).

http://www.torjo.com/win32gui/

Quelle horreur :-)!

--
AMcD®

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

Aurélien REGAT-BARREL a écrit :

[Win32]

Classes, constructeurs/destructeurs, héritage, polymorphisme,
fonctions virtuelles, ... sont des notions que l'on peut
identifier, à faible dose cela dit.

Je suis d'accord avec Aurélien. J'ai participé à des projets
(en C, sous OS/2 et sous Win32) dans lesquels une partie de
l'architecture reposait sur des messages postés entre threads
et qui étaient reçus par des fenêtre "invisibles" dont les
procédures de classes renvoyaient à la classe de base dans
le default du switch. Ajouté à l'utilisation de DLL chargées
dynamiquement comportant une procédure de classe exportée, ça
permet effectivement héritage, polymorphisme et fonctions
virtuelles, à grosses doses si on veut.

Ce genre de chose est aussi possible pour toute la partie
graphique, quand on souhaite se construire son propre gestionnaire
d'écran par exemple.

Mais bon, de nos jours, ça me paraît quand même plus intelligent
de s'appuyer sur des langages objets et/ou les librairies qui vont
avec, plutôt que de ré-inventer la roue avec du C/Win32.

Sauf si c'est pour se faire plaisir, bien entendu :-)

--
La normalité est dans l'instrument de mesure.
--GP

Aurélien REGAT-BARREL wrote:

Mais il n y a pas de structuration objet ( classes,

J'ai quand même envie de pinailler, surtout que je rédige un petit
article là dessus, ça va me permettre d'avoir votre avis. Win32 est
en C, certes, mais cela ne l'empêche pas d'être orienté objet. On y
retrouve beaucoups de concepts objets, on peut même être plus proche
de la théorie objet qu'avec des langages comme C++ ou même Java/C#.
Classes, constructeurs/destructeurs, héritage, polymorphisme,
fonctions virtuelles, ... sont des notions que l'on peut identifier,
à faible dose cela dit.

Bien entendu, l'API Win32 permet de manipuler des "objets" (via des handles
opaques). Ca prouve que la notion d'objet est plus une question de
conception que de langage d'implémentation. Ceci-dit, c'est nettement plus
facile de faire de l'objet (conceptuel) avec un langage orienté objet qu'en
C de grand-papa ;-)

On peut "apercevoir" la notion d'héritage à travers de méthodes comme
CloseHandle, DuplicateHandle, WaitForXXXObjects.

En ce qui concerne le polymorphisme et les fonctions virtuelles , c'est un
"détail" d'implémentation dont l'objectif principal est justement de ne
*pas* être visible depuis l'extérieur. Donc, savoir si Win32 est polymorphe,
on s'en fiche pas mal en tant que simple utilisateur de Win32!

Arnaud

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

Aurélien REGAT-BARREL wrote:

> J'ai quand même envie de pinailler, surtout que je rédige un petit
> article là dessus, ça va me permettre d'avoir votre avis. Win32 est
> en C, certes, mais cela ne l'empêche pas d'être orienté objet.

En interne, c'est "conceptuellement" objet (je vais me faire tuer par les
puristes), t'as des blocs, tokens, privilèges, etc. Mais bon, c'est codé

en

C. Architecturellement pensé objet si tu veux, mais concrètement pas objet
au final...

C'est tout simplement orienté object ! et Concrètement c'est de la
programmation objet, architecture objet... par contre c'est pas formalisé
C++ , mais C pure. Faut pas confondre la forme et le fond, et si on avait eu
besoin de langage objet pour faire du OO ca se saurait ! :-)


VB

Vincent Burel wrote:

C'est tout simplement orienté object !

Oui, c'est ce que je sous-entend.

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

Heu, j'ai pas cru voir des surcharges, du polymorphisme, de l'héritage, etc.
dans les types, fonctions, etc. :-).

--
AMcD®

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

> Bien entendu, l'API Win32 permet de manipuler des "objets" (via des
handles opaques). Ca prouve que la notion d'objet est plus une question de
conception que de langage d'implémentation. Ceci-dit, c'est nettement plus
facile de faire de l'objet (conceptuel) avec un langage orienté objet
qu'en C de grand-papa ;-)

Of course. C'est juste par masturbation intellectuelle que je me suis livré
à cette comparaison. Cela dit je pense que ça peut donner un apperçu
intéressant de Win32.

On peut "apercevoir" la notion d'héritage à travers de méthodes comme
CloseHandle, DuplicateHandle, WaitForXXXObjects.

En ce qui concerne le polymorphisme et les fonctions virtuelles , c'est un
"détail" d'implémentation dont l'objectif principal est justement de ne
*pas* être visible depuis l'extérieur. Donc, savoir si Win32 est
polymorphe, on s'en fiche pas mal en tant que simple utilisateur de Win32!

Polymorphisme oui je pense en effet à des fonctions du style DeleteObject
qui accepte un HGDIOBJ qui est en quelque sorte la super classe des objets
GDI (HBRUSH, HPEN, ...).
Pour DuplicateHandle j'avais pas percuté, c'est vrai que y'a de la copie
polymorphique (idiome clone). Quoique c'est le handle qui est dupliqué, pas
l'objet. Ca m'arrange pas.
Je viens de tilter par contre, un handle c'est un peu un pointeur
intelligent type shared_ptr (qui marche avec compteur de référence).
DuplicateHandle ça serait l'opérateur de recopie...
Polymorphisme et surtout fonctions virtuelles, attends de lire la suite, je
suis allé chercher très loin le truc...

Heu, il n'y a rien de ça dans Win32. Tu confonds avec MFC non ? Bon, c'est
vrai Qu'un CreatePen() suivi d'un DeleteObject(), ça fait furieusement
penser construteur/destructeur...

Non non je confonds pas avec MFC. Constructeur/Destructeur c'est vrai que
c'est un peu ça, mais je pensais plus objet que ça encore, où ils sont
appelés automatiquement par le système en début/fin de vie de l'objet...

Classes, constructeurs/destructeurs, héritage, polymorphisme,
fonctions virtuelles, ... sont des notions que l'on peut
identifier, à faible dose cela dit.

Je suis d'accord avec Aurélien. J'ai participé à des projets
(en C, sous OS/2 et sous Win32) dans lesquels une partie de
l'architecture reposait sur des messages postés entre threads
et qui étaient reçus par des fenêtre "invisibles" dont les
procédures de classes renvoyaient à la classe de base dans
le default du switch. Ajouté à l'utilisation de DLL chargées
dynamiquement comportant une procédure de classe exportée, ça
permet effectivement héritage, polymorphisme et fonctions
virtuelles, à grosses doses si on veut.

Ce genre de chose est aussi possible pour toute la partie
graphique, quand on souhaite se construire son propre gestionnaire
d'écran par exemple.

Tout à fait, c'est essentiellement sur les fenêtres et les messages que mon
analyse se porte. Bienque on retrouve des messages ailleurs genre LPC mais
c'est pas du Win32 ça (mais les RPC utilisent les LPC, et RPC c'est
Win32...mais bon).

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
- 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.
- WM_CREATE et WM_DESTROY peuvent être vus commes les constructeurs /
destructeurs des objets fenêtres
- 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)
- on peut imaginer l'héritage multiple en chainant 2 WndProc, mais j'ai
jamais croisé cette utilisation
- j'hésite à considérer le super-classing comme un héritage privé =>
composition

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...
- j'hésite à caser la méta-programmation avec RegisterClass qui permet de
créer des classes de fenêtres...
- j'hésite à qualifier de Delegate l'utilisation de SendMessage(
HWND_BROADCAST, ...)

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

--
Aurélien REGAT-BARREL

AMcD® a écrit :

Heu, j'ai pas cru voir des surcharges, du polymorphisme, de
l'héritage, etc. dans les types, fonctions, etc. :-).

Moi non plus. Le côté OO de Win32, il faut le voir
dans RegisterClass, CreateWindow, Post/SendMessage et
Set/GetWindowLong.

Avec RegisterClass, tu associes un nom de classe à du code, et
une quantité de mémoire d'instance. Avec CreateWindow, tu
instancies des objets en donnant le nom de classe, ton objet
est alors lié au code spécifié au moment du RegisterClass.
Avec Post/SendMessage, tu invoques des méthodes . Avec
Set/GetWindowLong, tu gères la mémoire d'instance. L'héritage,
il faut le coder soi-même, en "dur", ou avec les variables
d'instances. Avec le switch sur les messages dans les WindowProc
de l'arbre d'héritage, tu peux faire surcharge et polymorphisme.

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.

--

blague d'informaticien detectée

une autre plus subtile : ta mère en short

"Manuel Leclerc" <manuel.leclerc@alussinan.org> a écrit dans le message de
news: 41a6446d@neottia.net...

Avec RegisterClass, tu associes un nom de classe à du code, et
une quantité de mémoire d'instance. Avec CreateWindow, tu
instancies des objets en donnant le nom de classe, ton objet
est alors lié au code spécifié au moment du RegisterClass.
Avec Post/SendMessage, tu invoques des méthodes . Avec
Set/GetWindowLong, tu gères la mémoire d'instance. L'héritage,
il faut le coder soi-même, en "dur", ou avec les variables
d'instances. Avec le switch sur les messages dans les WindowProc
de l'arbre d'héritage, tu peux faire surcharge et polymorphisme.

Ah ben je constate avec plaisir que je suis pas si tordu que ça, ou alors on
est au moins deux :-)

--
Aurélien REGAT-BARREL

Aurelien REGAT-BARREL a écrit :

Ah ben je constate avec plaisir que je suis pas si tordu
que ça, ou alors on est au moins deux :-)

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 :-)

--
Software engineering cost is what matters to me ( I turned 40,
so I think different now....;-) )
--Hans Reiser

"Manuel Leclerc" <manuel.leclerc@alussinan.org> a écrit dans le message de
news: 41a6478b$1@neottia.net...

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 :-)

Pour le trodu je faisais référence à la fin de mon autre post : vtable,
Delegate, ...
Sinon oui j'ai bien conscience que ceux qui ont créé ça ne l'ont pas fait
pas hasard :-)

--
Aurélien REGAT-BARREL