Manipuler les fenetre Windows.

On Mon, 25 Aug 2003 21:00:48 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr> wrote:

Je pense que tu as fait une faute de frappe

C'est la façon "politiquement correcte" de désigner un troll ? ;-)

Le robot LE LEZ fonctionnerait peut etre un peu mieux
s'il etait programmé avec les MFC ...

MB

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
r4okkvco6eej2jcifvoba6euqvamm5el6p@4ax.com...

On Mon, 25 Aug 2003 21:00:48 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr> wrote:

Je pense que tu as fait une faute de frappe

C'est la façon "politiquement correcte" de désigner un troll ? ;-)

M.B. wrote:

Microsoft abandonne tout au profit de .NET et a standardise ses classes
en 'code managé' utilisable depuis n'importe quel langage comptatible .NET

Ou. C'est dommage que le C++ ne le soit pas.

Arnaud

"M.B." <mbinder@magicnet.com> a écrit dans le message de
news:bif3ml$tsh$2@news-reader3.wanadoo.fr...

Le robot LE LEZ fonctionnerait peut etre un peu mieux
s'il etait programmé avec les MFC ...

MB

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
r4okkvco6eej2jcifvoba6euqvamm5el6p@4ax.com...

On Mon, 25 Aug 2003 21:00:48 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr> wrote:

Je pense que tu as fait une faute de frappe

C'est la façon "politiquement correcte" de désigner un troll ? ;-)

D'un autre coté, on a un apperçu du résultat en voyant les posts M.B.

Chris

M.B. wrote:

"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
bidmcr$joq$1@news-reader1.wanadoo.fr...


Moi, j'utilise les MFC depuis 5 ans, contrairement a toi ..

En deux mots :
On peut arriver à faire ce qu'on veut,mais c'est tellement contre
intuitif et on a tellement souvent besoin de recourir à des appels
windows natifs que les MFC rendent la programmation windows bien plus
complexe qu'elle ne pourraît être.

Euh, non, c'est pas vrai du tout ca.
Un exemple ?
Voir la suite de mon post pour 4 exemples.

Quelques exemples que j'ai vraiment eu (je ne peux pas en produire plus,
j'ai seulement effleuré les MFC, avant de passer à QT que je maîtrisais
mieux en 5 minutes que les MFC en 2 semaines) :

Ca se voit.
Et c'est justement le point de vue que je veux montrer : Les MFC ne sont

pas aisées d'accès, ce qui dénote d'un problème de conception, puisque
d'autre bibliothèques avec des objectif semblables (ou même plus
ambitieux (multi-plateforme, dialogues dynamiques...)) arrivent elle à
l'être.

- On a un contrôle de type slider, et on souhaite que le programme soit
averti dès que l'utilisateur en change la valeur.

Meme chose, en MFC, c'est immediat.

Peut-tu poster un bout de code immédiat qui fasse ça s'il te plait ?
S'il y a une autre façon de faire que celle que j'ai décrite dans mon
post, et qui n'a RIEN d'immédiate, je souhaite la connaître.

- Toujours avec notre slider, je veux définir les limites min et et du
slider
* En QT : Dans l'éditeur de dialogue, je tappe la valeur min et max.
Je pourrais tout aussi bien la saisir dans le code

* En MFC, l'éditeur de dialogues possède bien un liste de propriétés
pour tout objet, mais des choses aussi "farfelues" qu'un min et un max
pour un slider n'en font bien évidemment pas partie, on est obligé
d'aller dans le code.

Il suffit de surcharger la methode virtuelle d'initialisation.

C'est bien ce que j'ai dit : L'éditeur de dialgue est très limité et on
est obligé d'aller dans la code pour faire la moindre action de base.
Dommage pour un produit "visual".
Je pense d'ailleur que le succès de VB dans certains dommaines est
grandement dû au fait qu'il dispose depuis longtemps d'un éditeur de
dialogue qui est vraiment fonctionnel.

- Pire encore : Je veux créer du texte qui s'affiche sur fond rouge.
Oups, je voulais dire qui s'affiche en gras. L'exemple est similaire

pour le rouge, bien évidemment, mais légèrement plus complexe, puisque
QT tient compte des préférences de l'utilisateur en matière de couleur.

* Dans QT : L'éditeur de dialogue, ou alors dans le code :
QFont font = myWidget->font();
font.setBold(true);
myWidget.setFont(font);

* Dans MFC : Rien dans l'éditeur de dialogues. Dans le code, je n'ai
rien trouvé qui ne passe pas par l'API windows native (j'attend ici une
réponse du type : Il suffit de faire... Ca m'intéresse).

Voir plus haut

Encore une fois, peut-tu poster un bout de code. Comme je l'ai déjà
indiqué sur ce point, je suis curieux de voir le code. J'ai posté le
code en QT.

Les MFC offrent toutes les caracteristiques que tu attends, et en toute
simplicite.

Je n'ai rien vu de simple dans les MFC. Sauf peut-être comparé à du
win32 natif. As-tu essayé d'autres bibliothèques comme celles que j'ai
cité ? J'ai l'impression que (si tu arrive à abstraire le fait que tu
connais les MFC par coeur mais pas cette bibliothèque) tu vas
redécouvrir ce que le mot "simple" veut dire.

Quant à ce que j'attend, qu'en sais tu ?

J'attend entre autre des boîtes de dialogue de taille variable. Pourquoi
ne m'as-tu pas répondu sur ce dernier exemple ?

J'attend aussi que toute personne venant travailler dans notre
environnement (et qui sont plutôt orientés modélisation, perception,
automatisme, synthèse d'image et réalité virtuelle) et connaissant les
bases de C++ soit capable de bricoler une petite IHM simplement, en 1/2
journée, sans passer 2 mois à se former à une bibliothèque d'IHM.
A l'époque où nous utilisions les MFC, la plupart de nos "IHM" étaient
en mode console. Nous sommes passés à QT, et depuis ce but est réalisé.
Et aucun de ces développeurs n'a eu besoin de vraiment "apprendre" QT
pour parvenir à ce but (pour des IHM plus complexes, un véritable
apprentissage aurait probablement été nécessaire). Ils ont fonctionné
avec leur bon sens et l'aide ponctuelle de collègues, et ça suffisait.

Comme pour toute librairie de classes, il ne faut pas negliger la phase
d'apprentissage.

Quand deux bibliothèque offrant les mêmes fonctionnalités demandent des
phases d'apprentissage différentes de plusieurs ordres de grandeur, je
persiste à dire que l'une des deux est mal faite.

--
Loïc

"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
big9h1$n37$1@news-reader5.wanadoo.fr...

Et c'est justement le point de vue que je veux montrer : Les MFC ne sont
pas aisées d'accès, ce qui dénote d'un problème de conception, puisque
d'autre bibliothèques avec des objectif semblables (ou même plus
ambitieux (multi-plateforme, dialogues dynamiques...)) arrivent elle à
l'être.

Non, non, tres facile d'acces. Tu es parti avec une opinion negative et
tu n'as pas voulu approfondir. Dans le cas contraire, tu te serais
rendu compte de la simplicite des MFC.

- On a un contrôle de type slider, et on souhaite que le programme soit
averti dès que l'utilisateur en change la valeur.

Meme chose, en MFC, c'est immediat.

Peut-tu poster un bout de code immédiat qui fasse ça s'il te plait ?
S'il y a une autre façon de faire que celle que j'ai décrite dans mon
post, et qui n'a RIEN d'immédiate, je souhaite la connaître.

Il y a dans Visual C++ 6.0 un 'class wizard'. Tu le lances quand tu edites
ta boite de dialogue, tu choisis l'element de ta boite sur lequel tu veux
intercepter un evenement, tu choisis la classe dans laquelle sera ajoutee
la methode de reaction a l'evenement, tu choisis un nom pour cette methode,
ou tu laisses celui par defaut, et l'outil te genere une methode vide
que tu remplis avec ton code. Il n'y a pas un caractere de code a taper.

- Toujours avec notre slider, je veux définir les limites min et et du
slider
* En QT : Dans l'éditeur de dialogue, je tappe la valeur min et max.
Je pourrais tout aussi bien la saisir dans le code

* En MFC, l'éditeur de dialogues possède bien un liste de propriétés
pour tout objet, mais des choses aussi "farfelues" qu'un min et un max
pour un slider n'en font bien évidemment pas partie, on est obligé
d'aller dans le code.

Il suffit de surcharger la methode virtuelle d'initialisation.

C'est bien ce que j'ai dit : L'éditeur de dialgue est très limité et on
est obligé d'aller dans la code pour faire la moindre action de base.
Dommage pour un produit "visual".
Je pense d'ailleur que le succès de VB dans certains dommaines est
grandement dû au fait qu'il dispose depuis longtemps d'un éditeur de
dialogue qui est vraiment fonctionnel.

L'editeur de dialogue est assez complet. Tu selectionnes l'element, clic
droit, proprietes, et tu regles. Effectivement le min et le max du slider
ne peuvent pas etre regle comme ca, mais c'est un detail, et 2 lignes
dans la methode d'initialisation de la classe associees reglent tres
simplement le probleme. De memoire, CSlider.SetMin() et SetMax().

- Pire encore : Je veux créer du texte qui s'affiche sur fond rouge.
Oups, je voulais dire qui s'affiche en gras. L'exemple est similaire

pour le rouge, bien évidemment, mais légèrement plus complexe, puisque
QT tient compte des préférences de l'utilisateur en matière de couleur.

* Dans QT : L'éditeur de dialogue, ou alors dans le code :
QFont font = myWidget->font();
font.setBold(true);
myWidget.setFont(font);

* Dans MFC : Rien dans l'éditeur de dialogues. Dans le code, je n'ai
rien trouvé qui ne passe pas par l'API windows native (j'attend ici une
réponse du type : Il suffit de faire... Ca m'intéresse).

Voir plus haut

Encore une fois, peut-tu poster un bout de code. Comme je l'ai déjà
indiqué sur ce point, je suis curieux de voir le code. J'ai posté le
code en QT.

Pas trouve le code en Qt? Et je suis encore en vacances jusqu'a lundi
prochain. Faudra attendre la semaine prochaine pour que je relance mon
(vieux) visual studio 6 (je suis passe depuis a C# sur Visual studio .net)

L'editeur permet de dimensionner les boites de dialogues, la couleur, la
taille, la police du texte, le gras et tout et tout ..
Aucun probleme la non plus.

Les MFC offrent toutes les caracteristiques que tu attends, et en toute
simplicite.

Je n'ai rien vu de simple dans les MFC. Sauf peut-être comparé à du
win32 natif. As-tu essayé d'autres bibliothèques comme celles que j'ai
cité ? J'ai l'impression que (si tu arrive à abstraire le fait que tu
connais les MFC par coeur mais pas cette bibliothèque) tu vas
redécouvrir ce que le mot "simple" veut dire.

J'ai l'impression que tu ne connais absolument pas les MFC, donc je vois
pas bien comment comparer.

Quant à ce que j'attend, qu'en sais tu ?

J'attend entre autre des boîtes de dialogue de taille variable. Pourquoi
ne m'as-tu pas répondu sur ce dernier exemple ?

J'attend aussi que toute personne venant travailler dans notre
environnement (et qui sont plutôt orientés modélisation, perception,
automatisme, synthèse d'image et réalité virtuelle) et connaissant les
bases de C++ soit capable de bricoler une petite IHM simplement, en 1/2
journée, sans passer 2 mois à se former à une bibliothèque d'IHM.
A l'époque où nous utilisions les MFC, la plupart de nos "IHM" étaient
en mode console. Nous sommes passés à QT, et depuis ce but est réalisé.
Et aucun de ces développeurs n'a eu besoin de vraiment "apprendre" QT
pour parvenir à ce but (pour des IHM plus complexes, un véritable
apprentissage aurait probablement été nécessaire). Ils ont fonctionné
avec leur bon sens et l'aide ponctuelle de collègues, et ça suffisait.

Pour avoir fait travailler des etudiants differents en projet sur les
2 bibliotheques, les vitesses d'apprentissage etaient les memes.
Je repette, tu ne connais pas les MFC. Tous cela est tres intuitif.

Comme pour toute librairie de classes, il ne faut pas negliger la phase
d'apprentissage.

Bibliotheque, pas librairie, en francais.

Quand deux bibliothèque offrant les mêmes fonctionnalités demandent des
phases d'apprentissage différentes de plusieurs ordres de grandeur, je
persiste à dire que l'une des deux est mal faite.

Oui, si c'etait le cas, mais ca ne l'est pas.

MB

P.S. Si t'insistes je te posterai un bout de code apres reprise du boulot.
Mais quel interet puisqu'il est genere automatiquement ?

M.B. wrote:

"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
big9h1$n37$1@news-reader5.wanadoo.fr...

Et c'est justement le point de vue que je veux montrer : Les MFC ne sont
pas aisées d'accès, ce qui dénote d'un problème de conception, puisque
d'autre bibliothèques avec des objectif semblables (ou même plus
ambitieux (multi-plateforme, dialogues dynamiques...)) arrivent elle à
l'être.

Non, non, tres facile d'acces. Tu es parti avec une opinion negative et

tu n'as pas voulu approfondir.

En l'occurence, la seule expériende de programmation d'IHM que j'avais
pu avoir auparavant était avec Access de Microsoft. Et j'avais plutôt
aimé. Je ne pense donc pas être parti avec un a priori négatif sur la
façon dont Microsoft pouvait fournir une bibliothèque d'IHM.

Dans le cas contraire, tu te serais
rendu compte de la simplicite des MFC.

J'ai fait 2 petits projets avec une IHM de base, et j'ai eu tout le long
l'impression de devoir batailler sans cesse contre les MFC au lieu de
travailler avec. Par exemple, pour le coup de l'évènement des sliders
qui se trouve dans la boîtes de dialogue la contenant (et non pas
associé au slider), j'ai réellement cherché longtemps avant, en
désespoir de cause, de mettre en place un timer qui va scrutter
régulièrement le slider. Je n'ai appris la manière "propre" de faire que
bien plus tard et par hasard.

Tu peux dire ce que tu veux, ce n'était pas simple. C'est simple à faire
une fois qu'on sait comment faire, ce n'est pas simple à découvrir par
soi même.

Pour information, j'ai ensuite fait un autre petit développement en C++
builder, et là je n'ai eu aucun problème à m'approprier la bibliothèque.

Par la suite, j'ai découvert QT et là non plus, aucun problème.

Dans des domaines non graphiques, je n'ai pas eu le sentiment de
batailler avec d'autres biblithoèques que je découvrais (blitz, boost,
diverse API de commande de cartes d'acquisitions, le code généré par
Lex/Yacc, OpenGlPerformer, OpenGVS...)

Le seul autre cas ou j'ai vaguement eu ce sentiment de frustration était
avec Xerces, et encore, la fonctionnalité que j'avais désespérement
chercé a été ajoutée dans la release suivante.

- On a un contrôle de type slider, et on souhaite que le programme soit
averti dès que l'utilisateur en change la valeur.

Meme chose, en MFC, c'est immediat.

Peut-tu poster un bout de code immédiat qui fasse ça s'il te plait ?
S'il y a une autre façon de faire que celle que j'ai décrite dans mon
post, et qui n'a RIEN d'immédiate, je souhaite la connaître.

Il y a dans Visual C++ 6.0 un 'class wizard'. Tu le lances quand tu edites
ta boite de dialogue, tu choisis l'element de ta boite sur lequel tu veux
intercepter un evenement,

C'est ce que j'ai fait, mais le seul évènement apparaissant pour un
slider est NM_OUTOFMEMORY. Ce que j'expliquais dans mon post précédent,
c'est que le fait que le slider bouge provoque un évènement non pas sur
le slider, mais sur la boîte de dialogue qui le contient. Effectivement,
une fois qu'on sait ça (non documenté dans la doc de slider), on arrive
à ses fin. Mais je maintiens que ce n'est pas un comportement intuitif.

tu choisis la classe dans laquelle sera ajoutee
la methode de reaction a l'evenement, tu choisis un nom pour cette methode,
ou tu laisses celui par defaut, et l'outil te genere une methode vide
que tu remplis avec ton code. Il n'y a pas un caractere de code a taper.

[...]

L'editeur de dialogue est assez complet. Tu selectionnes l'element, clic
droit, proprietes, et tu regles. Effectivement le min et le max du slider
ne peuvent pas etre regle comme ca, mais c'est un detail, et 2 lignes
dans la methode d'initialisation de la classe associees reglent tres
simplement le probleme. De memoire, CSlider.SetMin() et SetMax().

Tu appelle ça un détail ! Un slider sans min et max n'a pas de sens. Les
propriétés que tu peux modifier sont en nombre totalement insuffisante
par rapport à une utilisation basique de la classe. Et ce n'est pas un
exemple particulier.
Il n'y a rien dans la fenêtre de propriété pour changer la police ou la
couleur de quelque widget que ce soit
On ne peut pas déterminer le nombre de caractères d'une edit box
On ne peut fixer les min et max ni s'une scrollbar, ni d'un slider, ni
d'une spinbox, ni d'une editbox numérique, ni d'une progress bar...
On ne peut pas remplir ou même nommer les différents onglets d'un groupe
d'onglets (Tab Control) (C'est tellement surprenant que je suis enclin à
croire que c'est possible, mais que je n'ai pas vu comment le faire,
mais en tout cas rien dans la boîte de propriété n'indique comment le
faire).
Et je peux encore aligner plein d'autres exemples.

Je suis d'accord qu'on peut pallier par le code aux déficiences de
l'éditeur de dialogues, il n'en reste pas moins que cet éditeur est le
pire que j'ai vu.

[...] Je veux créer du texte qui s'affiche [...]en gras.

* Dans QT : L'éditeur de dialogue, ou alors dans le code :
QFont font = myWidget->font();
font.setBold(true);
myWidget.setFont(font);

* Dans MFC : Rien dans l'éditeur de dialogues. Dans le code, je n'ai
rien trouvé qui ne passe pas par l'API windows native (j'attend ici une
réponse du type : Il suffit de faire... Ca m'intéresse).

Pas trouve le code en Qt?

C'est les trois lignes de code juste au dessus.

Et je suis encore en vacances jusqu'a lundi
prochain. Faudra attendre la semaine prochaine pour que je relance mon
(vieux) visual studio 6 (je suis passe depuis a C# sur Visual studio .net)

L'editeur permet de dimensionner les boites de dialogues, la couleur, la
taille, la police du texte, le gras et tout et tout ..
Aucun probleme la non plus.

Si tu me montre ça, tu arrivera à me montrer ce que 3 personnes
travaillant depuis plusieurs années avec les MFC dans 3 boîtes
différentes n'ont jamais pu me montrer. D'avance bravo !

Les MFC offrent toutes les caracteristiques que tu attends, et en toute
simplicite.

Je n'ai rien vu de simple dans les MFC. Sauf peut-être comparé à du
win32 natif. As-tu essayé d'autres bibliothèques comme celles que j'ai
cité ? J'ai l'impression que (si tu arrive à abstraire le fait que tu
connais les MFC par coeur mais pas cette bibliothèque) tu vas
redécouvrir ce que le mot "simple" veut dire.

J'ai l'impression que tu ne connais absolument pas les MFC, donc je vois
pas bien comment comparer.

Quant à ce que j'attend, qu'en sais tu ?

J'attend entre autre des boîtes de dialogue de taille variable. Pourquoi
ne m'as-tu pas répondu sur ce dernier exemple ?

J'attend aussi que toute personne venant travailler dans notre
environnement (et qui sont plutôt orientés modélisation, perception,
automatisme, synthèse d'image et réalité virtuelle) et connaissant les
bases de C++ soit capable de bricoler une petite IHM simplement, en 1/2
journée, sans passer 2 mois à se former à une bibliothèque d'IHM.
A l'époque où nous utilisions les MFC, la plupart de nos "IHM" étaient
en mode console. Nous sommes passés à QT, et depuis ce but est réalisé.
Et aucun de ces développeurs n'a eu besoin de vraiment "apprendre" QT
pour parvenir à ce but (pour des IHM plus complexes, un véritable
apprentissage aurait probablement été nécessaire). Ils ont fonctionné
avec leur bon sens et l'aide ponctuelle de collègues, et ça suffisait.

Pour avoir fait travailler des etudiants differents en projet sur les
2 bibliotheques, les vitesses d'apprentissage etaient les memes.

Ce n'est pas ce que j'ai constaté dans mon environnement. Pour info,
quel était le niveau initial des étudiants en C++ ? Et quel était la
durée du projet ? Et était-il centré principalement sur l'IHM, ou bien
n'était-ce qu'un à côté ?

Je repette, tu ne connais pas les MFC. Tous cela est tres intuitif.

Formulé autrement : Je ne connais pas les MFC, je ne connais pas QT,
j'arrive néanmoins à faire ce que je veux avec QT, pas avec les MFC.
C'est peut-être barbare comme critère, mais comme dans mon environnement
je ne suis pas le seul à avoir remarqué ça, je pense que ce n'est pas
totalement sans valeur.

Comme pour toute librairie de classes, il ne faut pas negliger la phase
d'apprentissage.

Bibliotheque, pas librairie, en francais.

Effectivement, mais je n'allais pas pinailler en corrigeant cette erreur
(qui est dans ton texte...). ;)

P.S. Si t'insistes je te posterai un bout de code apres reprise du boulot.
Mais quel interet puisqu'il est genere automatiquement ?

Juste le truc pour mettre le texte d'une éditbox en gras. Soit le code
source, soit la manip sous l'éditeur. Merci.

--
Loïc

M.B. wrote:

Pour avoir fait travailler des etudiants differents en projet sur les
2 bibliotheques, les vitesses d'apprentissage etaient les memes.
Je repette, tu ne connais pas les MFC. Tous cela est tres intuitif.

Ben euh... quand j'ai débuté a coder, c'etait avec Visual basic (faut
bien debuter!!!) : simple, intuitif etc...
Ensuite je suis passé au C++, et la deux choix ce sont posés a moi :
borland C++ Builder et MS Visual C++.

J'ai teste VC, me disant "VB, c'est du Microsoft, VC ca va etre
tranquille...
Raté, j'ai rien compris. au bout de 10 minutes, j'ai testé C++ builder,
et ho, joie... J'ai retrouvé mes petits de VB!
Un comble, Borland meilleur a reproduire une interface que Microsoft
avait avec VB.

Donc pour le moment je me force a compiler avec VC (DLL en C++, avec le
mangling different de borland, ben ca passe chez personne :( ), mais
developpe au maximum avec Borland!
Et VC, c'est sans MFC (abandon a chaque tentative, OK tentative de 5
minutes, mais c'est el temps que j'ai accordé a Borland...)

Bref, pour une personne qui ne connaissait aucun des deux outils
graphique, le choix est rapide!

"Martinez Jerome" <jerome.martinez@aenlever-orangefrance.com> a écrit dans
le message news: biiesc$1511@news.rd.francetelecom.fr...

M.B. wrote:

Pour avoir fait travailler des etudiants differents en projet sur les
2 bibliotheques, les vitesses d'apprentissage etaient les memes.
Je repette, tu ne connais pas les MFC. Tous cela est tres intuitif.

Ben euh... quand j'ai débuté a coder, c'etait avec Visual basic (faut
bien debuter!!!) : simple, intuitif etc...
Ensuite je suis passé au C++, et la deux choix ce sont posés a moi :
borland C++ Builder et MS Visual C++.

J'ai teste VC, me disant "VB, c'est du Microsoft, VC ca va etre
tranquille...
Raté, j'ai rien compris. au bout de 10 minutes, j'ai testé C++ builder,
et ho, joie... J'ai retrouvé mes petits de VB!
Un comble, Borland meilleur a reproduire une interface que Microsoft
avait avec VB.

Donc pour le moment je me force a compiler avec VC (DLL en C++, avec le
mangling different de borland, ben ca passe chez personne :( ), mais
developpe au maximum avec Borland!
Et VC, c'est sans MFC (abandon a chaque tentative, OK tentative de 5
minutes, mais c'est el temps que j'ai accordé a Borland...)

Bref, pour une personne qui ne connaissait aucun des deux outils
graphique, le choix est rapide!

Je ne connais pas le Builder de Borland. J'ai fait il y a qqs temps des
formations a VC++ + MFC (a leurs demandes) a des utilisateurs de Builder.

A la fin de la formation (4 jours), une grande majorite d'entre-eux avait
adopte VC++ et ne voulait plus entendre parler de Builder. Si si je t'assure
que c'est vrai.

Pourquoi ? Je n'irais pas jusqu'a dire que la qualite de la formation y
etait
pour beaucoup ...

Parce que ce sont des developpeurs en Informatique Industrielle. D'apres ce
qu'ils m'ont dit, VC++ leur permet de voir avec precision ce qui se passe,
le code qui est genere et de le comprendre. A l'inverse, Builder est
'presse-boutons', 'a la VB', et ne leur offrait pas la possibilite de
voir les goulots d'etranglement de leurs softs, puisqu'ils avaient des
contraintes
de surete de fonctionnement et de rapidite d'execution.

Les qualites de tel ou tel outil dependent pour beaucoup du type
d'application visee.

C'est tout ce que je peux dire sur Builder.

Mais si on continue sur cette voie, on a pas fini, a comparer les outils,
les bibliotheques, les langages, et pourquoi pas les systemes
d'exploitations.

MB

Arnaud Meurgues wrote:

M.B. wrote:

Microsoft abandonne tout au profit de .NET et a standardise ses
classes en 'code managé' utilisable depuis n'importe quel langage
comptatible .NET

Ou. C'est dommage que le C++ ne le soit pas.

Ne soit pas quoi? Compatible NET? Il l'est! Ca s'appelle le "managed C++".

Le défaut, c'est qu'une bonne partie des fonctionnalités "avancées" de C++
(templates, destructeurs synchrones, héritage multipe d'implémentation) ne
sont pas utilisables dans les portions de code managé. Ceci-dit, comme on
peut mélanger le code managé et non-managé dans un fichier et appeler l'un
depuis l'autre, c'est un défaut somme toute assez limité.

Arnaud