Pour utiliser les fonctions systeme windows comme les sockets, les
timers, les threads, enfin ce genre de chose en utilisant C++, existe t
il d autres bibliotheques que la win32, la MFC et l OWL ?
Pour utiliser les fonctions systeme windows comme les sockets, les timers, les threads, enfin ce genre de chose en utilisant C++, existe t il d autres bibliotheques que la win32, la MFC et l OWL ?
Win32, c'est un ensemble de fonctions, structures, variables, etc., permettant d'écrire des applications... Win32 :-). Des applications Windows quoi. Cette API (Win32) est principalement constituée de DLLs. Y résident les fonctions de Win32 donc.
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu appelles toi-même les fonctions de Win32 en fournissant toi-même les paramètres, en implémentant toi-même la boucle de message, la fonction de fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette mixture est abstraite et "cachée" par ces surcouches ce qui, d'après certains, facilite la programmation Windows. Pour une fois, je ne ferai pas de commentaire.
MFC c'est la librairie de classes de Microsoft. OWL celle de Borland.
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
-- AMcD®
http://arnold.mcdonald.free.fr/
dom wrote:
Bonjour,
Pour utiliser les fonctions systeme windows comme les sockets, les
timers, les threads, enfin ce genre de chose en utilisant C++, existe
t il d autres bibliotheques que la win32, la MFC et l OWL ?
Win32, c'est un ensemble de fonctions, structures, variables, etc.,
permettant d'écrire des applications... Win32 :-). Des applications Windows
quoi. Cette API (Win32) est principalement constituée de DLLs. Y résident
les fonctions de Win32 donc.
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu
appelles toi-même les fonctions de Win32 en fournissant toi-même les
paramètres, en implémentant toi-même la boucle de message, la fonction de
fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout
ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette
mixture est abstraite et "cachée" par ces surcouches ce qui, d'après
certains, facilite la programmation Windows. Pour une fois, je ne ferai pas
de commentaire.
MFC c'est la librairie de classes de Microsoft. OWL celle de Borland.
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications
Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je
schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux
directement appeler toi-même les fonctions.
Pour utiliser les fonctions systeme windows comme les sockets, les timers, les threads, enfin ce genre de chose en utilisant C++, existe t il d autres bibliotheques que la win32, la MFC et l OWL ?
Win32, c'est un ensemble de fonctions, structures, variables, etc., permettant d'écrire des applications... Win32 :-). Des applications Windows quoi. Cette API (Win32) est principalement constituée de DLLs. Y résident les fonctions de Win32 donc.
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu appelles toi-même les fonctions de Win32 en fournissant toi-même les paramètres, en implémentant toi-même la boucle de message, la fonction de fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette mixture est abstraite et "cachée" par ces surcouches ce qui, d'après certains, facilite la programmation Windows. Pour une fois, je ne ferai pas de commentaire.
MFC c'est la librairie de classes de Microsoft. OWL celle de Borland.
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
-- AMcD®
http://arnold.mcdonald.free.fr/
dom
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...) MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications
Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je
schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux
directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système
Windows. Mais il n y a pas de structuration objet ( classes,
constructeurs, heritage ...)
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche ?
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...) MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
dom
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...) MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche pour les sockets, les timers, les threads ...?
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications
Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je
schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux
directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système
Windows. Mais il n y a pas de structuration objet ( classes,
constructeurs, heritage ...)
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche pour les sockets, les timers, les threads ...?
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...) MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche pour les sockets, les timers, les threads ...?
AMcD®
dom wrote:
Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...)
Pas dans Win32 pur non.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Que veux-tu de plus que MFC par exemple ? Toutes les fonctions de Win32 sont encapsulées dans MFC. Tu as CSOCKET, CTHREAD, etc.
-- AMcD®
http://arnold.mcdonald.free.fr/
dom wrote:
Mais il n y a pas de structuration objet ( classes,
constructeurs, heritage ...)
Pas dans Win32 pur non.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche ?
Que veux-tu de plus que MFC par exemple ? Toutes les fonctions de Win32 sont
encapsulées dans MFC. Tu as CSOCKET, CTHREAD, etc.
Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...)
Pas dans Win32 pur non.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Que veux-tu de plus que MFC par exemple ? Toutes les fonctions de Win32 sont encapsulées dans MFC. Tu as CSOCKET, CTHREAD, etc.
-- AMcD®
http://arnold.mcdonald.free.fr/
Arnaud Debaene
dom wrote:
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...)
Non, l'API Win32 est en C de manière à être le plus compatible possible avec tous les outils de développement.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc... ?? L'API Win32 couvre une quantité énorme de domaines qui n'ont rien à voir les uns avec les autres. De manière générale, MFC et OWL couvrent assez mal une grande partie de l'API Win32; il existe d'autres librairies plus spécialisées qui couvrent un besoin plus particulier mais le font mieux. Je citerais WTL et WxWidgets pour tout ce qui est fenêtrage/GUI, mais ce ne sont que des exemples parmi d'autres.
Arnaud
dom wrote:
AMcD® a écrit :
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des
applications Windows sans utiliser Win32 puisque les fonctions du
système sont Win32 (je schématise). Par contre, tu n'es pas obligé
d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les
fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système
Windows. Mais il n y a pas de structuration objet ( classes,
constructeurs, heritage ...)
Non, l'API Win32 est en C de manière à être le plus compatible possible avec
tous les outils de développement.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage,
l'accès réseau, le threading, la cryptographie, etc... ?? L'API Win32 couvre
une quantité énorme de domaines qui n'ont rien à voir les uns avec les
autres. De manière générale, MFC et OWL couvrent assez mal une grande
partie de l'API Win32; il existe d'autres librairies plus spécialisées qui
couvrent un besoin plus particulier mais le font mieux. Je citerais WTL et
WxWidgets pour tout ce qui est fenêtrage/GUI, mais ce ne sont que des
exemples parmi d'autres.
Tu as donc Win32, au dessus MFC ou OWL. Tu ne pas pas coder des applications Windows sans utiliser Win32 puisque les fonctions du système sont Win32 (je schématise). Par contre, tu n'es pas obligé d'utiliser MFC ou OWL. Tu peux directement appeler toi-même les fonctions.
Donc win32 est un passage obligé pour acceder aux fonctions du système Windows. Mais il n y a pas de structuration objet ( classes, constructeurs, heritage ...)
Non, l'API Win32 est en C de manière à être le plus compatible possible avec tous les outils de développement.
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc... ?? L'API Win32 couvre une quantité énorme de domaines qui n'ont rien à voir les uns avec les autres. De manière générale, MFC et OWL couvrent assez mal une grande partie de l'API Win32; il existe d'autres librairies plus spécialisées qui couvrent un besoin plus particulier mais le font mieux. Je citerais WTL et WxWidgets pour tout ce qui est fenêtrage/GUI, mais ce ne sont que des exemples parmi d'autres.
Arnaud
JM
AMcD® a écrit :
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu appelles toi-même les fonctions de Win32 en fournissant toi-même les paramètres, en implémentant toi-même la boucle de message, la fonction de fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette mixture est abstraite et "cachée" par ces surcouches ce qui, d'après certains, facilite la programmation Windows. Pour une fois, je ne ferai pas de commentaire.
Moi j'en ferai un ;-) J'ai commencé avec les MFC et cela m'a pas mal aidé. Maintenant, j'utilise un peu plus directement win32, et j'évite d'utiliser trop de classes spécifiques aux mfc (pas toujours très pratiques à utiliser et parfois, et elle sont souvent limitées).
Mais pour la gestion des boites de dialogues, des messages... c'est tout de même pratique.
AMcD® a écrit :
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu
appelles toi-même les fonctions de Win32 en fournissant toi-même les
paramètres, en implémentant toi-même la boucle de message, la fonction de
fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout
ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette
mixture est abstraite et "cachée" par ces surcouches ce qui, d'après
certains, facilite la programmation Windows. Pour une fois, je ne ferai pas
de commentaire.
Moi j'en ferai un ;-)
J'ai commencé avec les MFC et cela m'a pas mal aidé.
Maintenant, j'utilise un peu plus directement win32, et j'évite
d'utiliser trop de classes spécifiques aux mfc (pas toujours très
pratiques à utiliser et parfois, et elle sont souvent limitées).
Mais pour la gestion des boites de dialogues, des messages... c'est tout
de même pratique.
MFC/OWL c'est une surcouche pour cliquouilleurs. En temps normal, tu appelles toi-même les fonctions de Win32 en fournissant toi-même les paramètres, en implémentant toi-même la boucle de message, la fonction de fenêtre etc. Pas avec MFC/OWL, qui sont des librairies qui encapsulent tout ce traitement bas-niveau qui rebute le plus grand nombre. Donc, toute cette mixture est abstraite et "cachée" par ces surcouches ce qui, d'après certains, facilite la programmation Windows. Pour une fois, je ne ferai pas de commentaire.
Moi j'en ferai un ;-) J'ai commencé avec les MFC et cela m'a pas mal aidé. Maintenant, j'utilise un peu plus directement win32, et j'évite d'utiliser trop de classes spécifiques aux mfc (pas toujours très pratiques à utiliser et parfois, et elle sont souvent limitées).
Mais pour la gestion des boites de dialogues, des messages... c'est tout de même pratique.
dom
Arnaud Debaene a écrit :
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
-- Domingo
Arnaud Debaene a écrit :
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage,
l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus
particulierement le threading (verrou, semaphore, detection de dead
lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
-- Domingo
Arnaud Debaene
dom wrote:
Arnaud Debaene a écrit :
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) a très bonne réputation pour ces domaines et a en plus le mérite d'être portable. Par contre, son modèle objet et tellement riche qu'il peut être un peu difficile à digérer au début.
En ce qui concerne l'accès réseau plus particulièrement, tout dépend à quel niveau d'abstraction tu veux te situer. tu as les sockets, diverses librairies objets encapsulant les sockets (mais évite les MFC pour çà!), WinInet pou tout ce qui est protocoles "web" (http, ftp, etc...), puis des modèles d'objets distribués plus complexes comme DCOM, .NET remoting ou Corba (plein d'ORBs différents disponibles).
Arnaud MVP - VC
dom wrote:
Arnaud Debaene a écrit :
MFC/OWL proposent une interface plus objet. Il n existe pas d autre
surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le
fenêtrage, l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus
particulierement le threading (verrou, semaphore, detection de dead
lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) a très bonne réputation pour
ces domaines et a en plus le mérite d'être portable. Par contre, son modèle
objet et tellement riche qu'il peut être un peu difficile à digérer au
début.
En ce qui concerne l'accès réseau plus particulièrement, tout dépend à quel
niveau d'abstraction tu veux te situer. tu as les sockets, diverses
librairies objets encapsulant les sockets (mais évite les MFC pour çà!),
WinInet pou tout ce qui est protocoles "web" (http, ftp, etc...), puis des
modèles d'objets distribués plus complexes comme DCOM, .NET remoting ou
Corba (plein d'ORBs différents disponibles).
MFC/OWL proposent une interface plus objet. Il n existe pas d autre surcouche ?
Si bien sûr, mais pour quel domaine exactement? le graphisme, le fenêtrage, l'accès réseau, le threading, la cryptographie, etc...
Arnaud
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) a très bonne réputation pour ces domaines et a en plus le mérite d'être portable. Par contre, son modèle objet et tellement riche qu'il peut être un peu difficile à digérer au début.
En ce qui concerne l'accès réseau plus particulièrement, tout dépend à quel niveau d'abstraction tu veux te situer. tu as les sockets, diverses librairies objets encapsulant les sockets (mais évite les MFC pour çà!), WinInet pou tout ce qui est protocoles "web" (http, ftp, etc...), puis des modèles d'objets distribués plus complexes comme DCOM, .NET remoting ou Corba (plein d'ORBs différents disponibles).
Arnaud MVP - VC
Dominique Vaufreydaz
Bonjour,
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
commoncpp2 peut-etre ton ami (attention a bien prendre la derniere version en browsant correctement sous sourceforce).
Verifier simplement qu'il n'y a pas de commentaire sur le code disant Todo: implement for Win32 (meme sur les classes WIN32 like)
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Merci pour vos reponses. Les domaines qui m interessent sont plus
particulierement le threading (verrou, semaphore, detection de dead
lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
commoncpp2 peut-etre ton ami (attention a bien prendre la derniere
version en browsant correctement sous sourceforce).
Verifier simplement qu'il n'y a pas de commentaire sur le code disant
Todo: implement for Win32 (meme sur les classes WIN32 like)
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Merci pour vos reponses. Les domaines qui m interessent sont plus particulierement le threading (verrou, semaphore, detection de dead lock, synchronisation) et l acces reseau( TCPIP, ftp, ...)
commoncpp2 peut-etre ton ami (attention a bien prendre la derniere version en browsant correctement sous sourceforce).
Verifier simplement qu'il n'y a pas de commentaire sur le code disant Todo: implement for Win32 (meme sur les classes WIN32 like)
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Aurélien REGAT-BARREL
> > Mais il n y a pas de structuration objet ( classes, > constructeurs, heritage ...)
Pas dans Win32 pur non.
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.
> MFC/OWL proposent une interface plus objet. Il n existe pas d autre > surcouche ?
OWL c'est mort depuis belle lurette non ? VCL a pris le pas il me semble (elle même est morte aussi non ?). Y'a VCF à voir, et pour des boutons etc... un truc que je n'ai pas encore eu le temps de tester mais qui parraît intéressant pour ceux qui aiment le C++ "moderne" : win32Gui. http://www.torjo.com/win32gui/
-- Aurélien REGAT-BARREL
> > Mais il n y a pas de structuration objet ( classes,
> constructeurs, heritage ...)
Pas dans Win32 pur non.
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.
> MFC/OWL proposent une interface plus objet. Il n existe pas d autre
> surcouche ?
OWL c'est mort depuis belle lurette non ? VCL a pris le pas il me semble
(elle même est morte aussi non ?).
Y'a VCF à voir, et pour des boutons etc... un truc que je n'ai pas encore eu
le temps de tester mais qui parraît intéressant pour ceux qui aiment le C++
"moderne" : win32Gui.
http://www.torjo.com/win32gui/
> > Mais il n y a pas de structuration objet ( classes, > constructeurs, heritage ...)
Pas dans Win32 pur non.
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.
> MFC/OWL proposent une interface plus objet. Il n existe pas d autre > surcouche ?
OWL c'est mort depuis belle lurette non ? VCL a pris le pas il me semble (elle même est morte aussi non ?). Y'a VCF à voir, et pour des boutons etc... un truc que je n'ai pas encore eu le temps de tester mais qui parraît intéressant pour ceux qui aiment le C++ "moderne" : win32Gui. http://www.torjo.com/win32gui/
