> 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
? Je m'étonne de ne jamais en avoir croisé (c'est ce qui me motive à en
écrire un).
> 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
? Je m'étonne de ne jamais en avoir croisé (c'est ce qui me motive à en
écrire un).
> 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
? Je m'étonne de ne jamais en avoir croisé (c'est ce qui me motive à en
écrire un).
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
l'ensemble, c'est tourner en rond. Les concept de programmations OO mis en
oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer que
ceux là.
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
l'ensemble, c'est tourner en rond. Les concept de programmations OO mis en
oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer que
ceux là.
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
l'ensemble, c'est tourner en rond. Les concept de programmations OO mis en
oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer que
ceux là.
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
> l'ensemble, c'est tourner en rond. Les concept de programmations OO mis
> oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
> pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer
> ceux là.
Justement, c'est parce que ça n'a rien de nouveau et parce que beaucoup de
monde pense que .Net c'est la révolution de la nouveauté innovatrice que
veux faire un petit article qui illustre ces principes dans la bonne
API Win32, et partant de là je pense enuite prolonger avec .Net en faisant
une étude de son mapping sur Win32.
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
> l'ensemble, c'est tourner en rond. Les concept de programmations OO mis
> oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
> pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer
> ceux là.
Justement, c'est parce que ça n'a rien de nouveau et parce que beaucoup de
monde pense que .Net c'est la révolution de la nouveauté innovatrice que
veux faire un petit article qui illustre ces principes dans la bonne
API Win32, et partant de là je pense enuite prolonger avec .Net en faisant
une étude de son mapping sur Win32.
> Parler aujourd'hui de l'API Win32, en montrant le côté orienté object de
> l'ensemble, c'est tourner en rond. Les concept de programmations OO mis
> oeuvre, pour la plupart par Xerox dans les années 70, ont été utilisé
> pendant 20 ans sans C++ , par Apple comme par Microsoft... pour citer
> ceux là.
Justement, c'est parce que ça n'a rien de nouveau et parce que beaucoup de
monde pense que .Net c'est la révolution de la nouveauté innovatrice que
veux faire un petit article qui illustre ces principes dans la bonne
API Win32, et partant de là je pense enuite prolonger avec .Net en faisant
une étude de son mapping sur Win32.
ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui définit
l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
cran au dessus que le ++... car plus flexible...
ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui définit
l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
cran au dessus que le ++... car plus flexible...
ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui définit
l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
cran au dessus que le ++... car plus flexible...
Vincent Burel wrote:
> ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui
> l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
> cran au dessus que le ++... car plus flexible...
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
Vincent Burel wrote:
> ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui
> l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
> cran au dessus que le ++... car plus flexible...
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
Vincent Burel wrote:
> ceci dit, je vous conseil aussi la lecture aussi du COM CookBook qui
> l'architecture OO COM Microsoft en "C", c'était déjà conceptuellement un
> cran au dessus que le ++... car plus flexible...
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
"Loïc Joly" wrote in message
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
COM c'est d'abord une structure d'objet standardisé, avec un protocole
d'appel standardisé, et une orientation client/serveur dans le sens ou
chaque objet est perçu comme un fournisseur de service (un objet tout
betement), à un programme client qui profite de ces services à travers des
interfaces logiciels (table de méthode). Certains langage ce sont adapté
pour pouvoir faire des objets compatible COM, le C++ de Microsoft est un
exemple.
Vous trouverez plein de topo sur le model COM, celui-ci de Microsoft est une
référence :
The COM Programmer's Cookbook
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_com_co.asp
où y'a concrètement des exemple 'C' et 'C++' comparé.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du C++
avant l'heure...
comme beaucoup d'autre architecture, que les programmeurs se sont construit
dans les années 80,90 en Pascal ou C et qui peuvent être similaire.
L'atout
majeur de COM reste son orientation vers la communication , c'est à dire
plus de donnée que de fonction, que de code. le C++ c'est un peu l'inverse :
trop, trop de fonction... à dégouter de faire justement du polymorphisme
:-), et c'est pourquoi personnellement je suis resté au "C".
La faille majeure du l'architecture COM est que la destruction est pas très
clairement établie... et entre les collections d'objet gérés par un FACTORY
CLASS et les divers RELEASE d'interface, y'a de quoi se mélanger les
pinceaux, et dans la pratique beaucoup de programmeur se sont fourvoyé ici,
et beaucoup d'objet COM ne respecte pas exactement le standart...
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
COM c'est d'abord une structure d'objet standardisé, avec un protocole
d'appel standardisé, et une orientation client/serveur dans le sens ou
chaque objet est perçu comme un fournisseur de service (un objet tout
betement), à un programme client qui profite de ces services à travers des
interfaces logiciels (table de méthode). Certains langage ce sont adapté
pour pouvoir faire des objets compatible COM, le C++ de Microsoft est un
exemple.
Vous trouverez plein de topo sur le model COM, celui-ci de Microsoft est une
référence :
The COM Programmer's Cookbook
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_com_co.asp
où y'a concrètement des exemple 'C' et 'C++' comparé.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du C++
avant l'heure...
comme beaucoup d'autre architecture, que les programmeurs se sont construit
dans les années 80,90 en Pascal ou C et qui peuvent être similaire.
L'atout
majeur de COM reste son orientation vers la communication , c'est à dire
plus de donnée que de fonction, que de code. le C++ c'est un peu l'inverse :
trop, trop de fonction... à dégouter de faire justement du polymorphisme
:-), et c'est pourquoi personnellement je suis resté au "C".
La faille majeure du l'architecture COM est que la destruction est pas très
clairement établie... et entre les collections d'objet gérés par un FACTORY
CLASS et les divers RELEASE d'interface, y'a de quoi se mélanger les
pinceaux, et dans la pratique beaucoup de programmeur se sont fourvoyé ici,
et beaucoup d'objet COM ne respecte pas exactement le standart...
"Loïc Joly" wrote in message
C'est un point que j'ai du mal à apprécier. J'ai l'impression que le
seul avantage de l'architecture objet COM sur l'architecture objet C++
est que Microsoft a développer des implémentations de cette architecture
pour plusieurs langages. Je serais heureux de découvrir que je me
trompe, ma connaissance de COM est récente, et donc limitée. Aurais tu
quelques exemples ?
COM c'est d'abord une structure d'objet standardisé, avec un protocole
d'appel standardisé, et une orientation client/serveur dans le sens ou
chaque objet est perçu comme un fournisseur de service (un objet tout
betement), à un programme client qui profite de ces services à travers des
interfaces logiciels (table de méthode). Certains langage ce sont adapté
pour pouvoir faire des objets compatible COM, le C++ de Microsoft est un
exemple.
Vous trouverez plein de topo sur le model COM, celui-ci de Microsoft est une
référence :
The COM Programmer's Cookbook
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_com_co.asp
où y'a concrètement des exemple 'C' et 'C++' comparé.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du C++
avant l'heure...
comme beaucoup d'autre architecture, que les programmeurs se sont construit
dans les années 80,90 en Pascal ou C et qui peuvent être similaire.
L'atout
majeur de COM reste son orientation vers la communication , c'est à dire
plus de donnée que de fonction, que de code. le C++ c'est un peu l'inverse :
trop, trop de fonction... à dégouter de faire justement du polymorphisme
:-), et c'est pourquoi personnellement je suis resté au "C".
La faille majeure du l'architecture COM est que la destruction est pas très
clairement établie... et entre les collections d'objet gérés par un FACTORY
CLASS et les divers RELEASE d'interface, y'a de quoi se mélanger les
pinceaux, et dans la pratique beaucoup de programmeur se sont fourvoyé ici,
et beaucoup d'objet COM ne respecte pas exactement le standart...
Vincent Burel wrote:
> "Loïc Joly" wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait des
défauts et qu'il n'était pas envisageable de le faire évoluer. En fait,
je viens de lire http://en.wikipedia.org/wiki/Software_componentry et
dans le chapitre "Differences between Object Oriented Programming and
Software Components", je me rend compte que je suis du côté de ceux qui
n'y voient pas vraiment de différences, autres qu'historiques.
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
Vincent Burel wrote:
> "Loïc Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait des
défauts et qu'il n'était pas envisageable de le faire évoluer. En fait,
je viens de lire http://en.wikipedia.org/wiki/Software_componentry et
dans le chapitre "Differences between Object Oriented Programming and
Software Components", je me rend compte que je suis du côté de ceux qui
n'y voient pas vraiment de différences, autres qu'historiques.
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
Vincent Burel wrote:
> "Loïc Joly" wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait des
défauts et qu'il n'était pas envisageable de le faire évoluer. En fait,
je viens de lire http://en.wikipedia.org/wiki/Software_componentry et
dans le chapitre "Differences between Object Oriented Programming and
Software Components", je me rend compte que je suis du côté de ceux qui
n'y voient pas vraiment de différences, autres qu'historiques.
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
"Loïc Joly" wrote in message
news:41a7b793$0$16348$Vincent Burel wrote:"Loïc Joly" wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
la compatibilité, c'est toujours dans une certaine douleur.Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Y'a des différences, philosophique notamment. L'idée de multi interface sur
un objet par exemple,
l'idée d'objet server, et de programme client, pouvant
être étendu à celle de client/server réseaux...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
oulah , le document date de 95, attention. le concept doit être bien plus
vieux, et son formalisme en "C" au sein de Microsoft aussi, Des composant
objet étaient déjà présent sur Win 3.11 (notamment dans le pack office)...
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
je voulais dire que le problème du "C++" pour le programmeur, c'est de
croire que tout est objet, et qu'il n'y a plus de donnée réellement. (ca
fait partie du débat précédent NEW vs MALLOC).
Ce qui fait qu'en C++ les
programmeur n'ont jamais autant pisser de ligne, et définit autant de
fonctions (méthode). L'objet COM, philosophiquement, fait une différence
plus nette entre l'objet (une class, une structure), et son port de
communication (son interface = ces méthodes). En C++ l'objet c'est un
monolithe DATA+METHOD, COM définit un objet comme une boite noir qui fait
qqc,
et un ensemble d'interface que l'on peut demander par un QueryInterface
pour manoeuvrer cet objet d'une manière ou d'une autre... c'est pas la même
approche.
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
news:41a7b793$0$16348$8fcfb975@news.wanadoo.fr...
Vincent Burel wrote:
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
la compatibilité, c'est toujours dans une certaine douleur.
Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Y'a des différences, philosophique notamment. L'idée de multi interface sur
un objet par exemple,
l'idée d'objet server, et de programme client, pouvant
être étendu à celle de client/server réseaux...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
oulah , le document date de 95, attention. le concept doit être bien plus
vieux, et son formalisme en "C" au sein de Microsoft aussi, Des composant
objet étaient déjà présent sur Win 3.11 (notamment dans le pack office)...
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
je voulais dire que le problème du "C++" pour le programmeur, c'est de
croire que tout est objet, et qu'il n'y a plus de donnée réellement. (ca
fait partie du débat précédent NEW vs MALLOC).
Ce qui fait qu'en C++ les
programmeur n'ont jamais autant pisser de ligne, et définit autant de
fonctions (méthode). L'objet COM, philosophiquement, fait une différence
plus nette entre l'objet (une class, une structure), et son port de
communication (son interface = ces méthodes). En C++ l'objet c'est un
monolithe DATA+METHOD, COM définit un objet comme une boite noir qui fait
qqc,
et un ensemble d'interface que l'on peut demander par un QueryInterface
pour manoeuvrer cet objet d'une manière ou d'une autre... c'est pas la même
approche.
"Loïc Joly" wrote in message
news:41a7b793$0$16348$Vincent Burel wrote:"Loïc Joly" wrote in message
Compatibles, mais dans la douleur (même si à ce que j'ai compris les ATL
améliorent la situation).
la compatibilité, c'est toujours dans une certaine douleur.Ok, merci, je vais regarder ça. J'espère y comprendre pourquoi ils ont
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un modèle
objet existant.
Y'a des différences, philosophique notamment. L'idée de multi interface sur
un objet par exemple,
l'idée d'objet server, et de programme client, pouvant
être étendu à celle de client/server réseaux...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
oulah , le document date de 95, attention. le concept doit être bien plus
vieux, et son formalisme en "C" au sein de Microsoft aussi, Des composant
objet étaient déjà présent sur Win 3.11 (notamment dans le pack office)...
Euh, désolé, là j'ai pas compris ce que tu voulais dire...
je voulais dire que le problème du "C++" pour le programmeur, c'est de
croire que tout est objet, et qu'il n'y a plus de donnée réellement. (ca
fait partie du débat précédent NEW vs MALLOC).
Ce qui fait qu'en C++ les
programmeur n'ont jamais autant pisser de ligne, et définit autant de
fonctions (méthode). L'objet COM, philosophiquement, fait une différence
plus nette entre l'objet (une class, une structure), et son port de
communication (son interface = ces méthodes). En C++ l'objet c'est un
monolithe DATA+METHOD, COM définit un objet comme une boite noir qui fait
qqc,
et un ensemble d'interface que l'on peut demander par un QueryInterface
pour manoeuvrer cet objet d'une manière ou d'une autre... c'est pas la même
approche.
Compatibles, mais dans la douleur (même si à ce que j'ai compris les
ATL améliorent la situation).
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un
modèle objet existant.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du
C++ avant l'heure...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait
des défauts et qu'il n'était pas envisageable de le faire évoluer.
Compatibles, mais dans la douleur (même si à ce que j'ai compris les
ATL améliorent la situation).
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un
modèle objet existant.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du
C++ avant l'heure...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait
des défauts et qu'il n'était pas envisageable de le faire évoluer.
Compatibles, mais dans la douleur (même si à ce que j'ai compris les
ATL améliorent la situation).
redéveloppé un modèle objet, plutôt que de normaliser l'ABI d'un
modèle objet existant.
Ceci dit, COM n'est pas une panassé, mais il faut avoué que c'est du
C++ avant l'heure...
Euh, le C++ date de 83, COM de 95 (ou selon ce qu'on compte comme date
de début, 79 et 93). Donc le côté avant l'heure, j'y crois pas trop...
Ce que j'ai du mal à comprendre c'est pourquoi, malgré son arrivée
tardive, n'a-t-il pas plus essayé de s'intégrer dans l'un des nombreux
existants au moins. Je suppose que c'est parce que l'existant avait
des défauts et qu'il n'était pas envisageable de le faire évoluer.
Vincent Burel wrote:
> Y'a des différences, philosophique notamment. L'idée de multi interface
> un objet par exemple,
Ce qui est la même philosophie que l'héritage multiple en C++, et même
les langages comme Java ont repris des bouts d'héritage multiple limités
pour permettre un objet multi-interface.
Si tu parles de OLE, ça date de 91. Et windows 3.11 date lui de 93. Dans
les deux cas, le concepts est postérieurs à C++ (CFront en était à la
version 3, les templates et exceptions existaient déjà, et le processus
de normalisation était en cours...).
Veux tu dire par là que COM est plus directif que C++, et que cette
directivité aide les gens à ne pas faire d'erreurs ?
Vincent Burel wrote:
> Y'a des différences, philosophique notamment. L'idée de multi interface
> un objet par exemple,
Ce qui est la même philosophie que l'héritage multiple en C++, et même
les langages comme Java ont repris des bouts d'héritage multiple limités
pour permettre un objet multi-interface.
Si tu parles de OLE, ça date de 91. Et windows 3.11 date lui de 93. Dans
les deux cas, le concepts est postérieurs à C++ (CFront en était à la
version 3, les templates et exceptions existaient déjà, et le processus
de normalisation était en cours...).
Veux tu dire par là que COM est plus directif que C++, et que cette
directivité aide les gens à ne pas faire d'erreurs ?
Vincent Burel wrote:
> Y'a des différences, philosophique notamment. L'idée de multi interface
> un objet par exemple,
Ce qui est la même philosophie que l'héritage multiple en C++, et même
les langages comme Java ont repris des bouts d'héritage multiple limités
pour permettre un objet multi-interface.
Si tu parles de OLE, ça date de 91. Et windows 3.11 date lui de 93. Dans
les deux cas, le concepts est postérieurs à C++ (CFront en était à la
version 3, les templates et exceptions existaient déjà, et le processus
de normalisation était en cours...).
Veux tu dire par là que COM est plus directif que C++, et que cette
directivité aide les gens à ne pas faire d'erreurs ?
