Tout comme sous Linux, le kernel 2.4 n'a par exemple jamais voulu booter sur ma passerelle aprés moûlts tentatives. Bon c'est tout, le 2.2 me convient très bien.
> > Nous n'imaginons pas comment être moins cher
> > que Linux. (rires)
>
> Si Steve fait marrer l'assistance, c'est plutôt
> qu'il est en train de se foutre de notre
> gueule ?
Un peu parano peut être ? C'est une simple plaisanterie sur le fait qu'il est difficile d'être moins cher que gratuit. Faut pas non plus chercher l'attaque frontale de partout...
> Rappelons à Steve que le logiciel gratuit n'est
> pas apparu avec Linux. Que MS utilise donc la
> même stratégie que celle qui lui a si bien
> réussi face au freeware Netscape 4.
Bah, aux dérniéres nouvelles, la part de marché de Microsoft dans les OS Desktop reste autour de 95% donc, quelle que soit leur stratégie, elle semble fonctionner...
Qu'est ce qu'il apelle "plantage" ton collégue ? Si c'est le freeze d'une task, un kill task résoud le probléme. Si c'est un BSOD / reboot, il faudrait qu'il s'inquiéte à propos de son hardware très sérieusement. J'ai eu une machine linux qui plantait aussi réguliérement, tous les 2 3 jours, et finalement aprés changement du hdd qui semblait mal en point, plus aucun probléme.
Le probléme c'est qu'il est extrêmement difficile de comparer la stabilité de Windows à Linux dans la mesure où les 2 ne fonctionnent pas du tout de la même maniére. Rien que par le fait de l'interface graphique, il faudrait comparer à Linux avec XFree de loadé ce qui est déjà un net handicap pour Linux.
Ce qui est clairement vrai et indéniable c'est que l'époque des plantages tous les quarts d'heure de Windows est révolue. Ici j'ai une machine sous XP et l'autre sous Linux, et les 2 se vautrent à peu prés autant c'est à dire une fois par mois, et bien souvent ce n'est pas rééllement la faute du systéme.
Les BSOD, ça n'existe PLUS sous WinXP. Je n'en ai jamais vu depuis que je l'utilise et je ne crois pas qu'on puisse encore en voir à moins de jouer avec des drivers matériels alpha / beta / programmés par mon voisin qui n'y connait rien. Les développeurs windows ne peuvent plus faire n'importe quoi et provoquer ces fameux BSOD.
Par contre, il arrive qu'une task se vautre comme ça arrive sous Linux (en tout cas à moi) et 99% du temps un kill task supprime le probléme.
Bref, je suis d'accord sur le fait que la stabilité n'est plus vraiment un argument en faveur de Linux et comme il a tant d'autres arguments en sa faveur, inutile de radoter sur la stabilité de Win9X
Faut pas oublier que .Net est loin d'avoir emporté l'adhésion pour le moment chez les développeurs. Le vrai concurrent à MFC pour moi, c'est WTL (Window Template Library). Pour ceux qui ne connaissent pas, c'est une sorte de réécriture des MFC qui corrige la plupart de ses défauts. C'est écrit par des développeur de Ms même si ça n'est pas supporté "officiellement" par Ms. Il eut peut être été plus intéréssant de comparer Qt à WTL.
Je sais pas, j'ai jamais été confronté à ce probléme... J'utilise Visual Studio depuis la version 6, et je suis récemment passé à la version .Net sans aucune incompatibilités avec mon code existant (plusieurs milliers de lignes). Peut être y avait il des problémes plus importants entre VC 4/5 et VC 6 ?
Je suis pas vraiment d'accord là dessus. Oui Ms offre dans Visual Studio des facilités aux programmeurs, des macros ou autres pour l'aider. Qui pourrait s'en plaindre ?
Maintenant si le programmeur est compétent et désire développer pour plusieurs plateformes et/ou en dév collaboratif, il va essaier d'écrire du code plus standard, ou au moins plusieurs versions avec des #define, sinon c'est qu'il ne sait pas programmer.
Posté par Dawm .
En réponse à la dépêche Qt contre MFC.
Évalué à 10.
Un article vraiment intéréssant, surtout que j'avais l'intention de me renseigner à propos de QT. Je donne ici mon avis en tant que développeur sous Win32 directement en API, je ne supporte pas les MFC aprés les avoir essayés.
En ce qui concerne le pseudo objet vs object, oui, c'est une évidence mais ce n'est pas vraiment la faute des MFC. Le fait est que toutes les surcouches comme MFC, WTL, ATL sont toutes fortement dépendantes de l'API Win32, qui est massivement écrite en C. Ca a des raisons, en particulier le faite que les bases de l'API n'ont peu ou prou pas changés depuis Windows 3.x, donc à une époque où le C++ n'était pas aussi fortement répandu. Donc d'un côté, c'est bien parce que la compatibilité ascendante est fortement assurée (99% des exe compilés pour win95 tournent sous winXP) mais de l'autre, effectivement, on reste dans un vieux modéle C.
La boucle de messages. Effectivement, elle demande un peu d'apprentissage. Néanmoins je trouve qu'à l'usage elle se révéle assez pratique et fait partie des quelques concepts à bien maitriser pour développer sous Win32. Est elle améliorable, sans doute, est ce vraiment un handicap : je ne pense pas
Au niveau de la simplicité de coding, je ne vois pas de grandes différences...
Si tu veux faire un EditBox en API, tu vas faire un CreateWindow avec les paramétres qui vont bien et voilà.
Sur la doc, certes MSDN n'est pas très facile à maitriser, mais c'est certainement la plus grosse base de documentation sur un OS qui existe. Et tu oublies de parles des newsgroups microsoft.* ou autres ng dans les hiérarchies "classiques" dans lesquels des développeurs experimentés Win32 api foisonnent, voir même des propres développeurs Microsft pour les ng ms.* Je ne peux pas préjuger de la qualité de la doc de Qt ne l'ayant pas lu ni pratiqué, mais honnêtement je ne me souviens pas avoir eu un probléme sans trouver la solution dans les 1 à 2 heures suivantes en win32 API (et c'est encore plus vrai en MFC vu le nombre de sites dédiés).
Les CString sont une daube, aucun doute là dessus. Mais pourquoi ne pas utiliser std::string qui convient dans 95% des cas ?
Tu dis qu'il n'y a pas de ressources dans QT, mais quel autre systéme remplit ce rôle alors ?
Sinon pour moi, le gros avantage de QT c'est avant tout qu'il est multiplateformes.. C'est un réél intêret pour celui qui veut développer un prorgramme graphique à destination de plusieurs OS
[^] # Re: Stabilité de Windows.
Posté par Dawm . En réponse à la dépêche Linux a gagné une bataille contre Microsoft. Évalué à 2.
[^] # Re: rires
Posté par Dawm . En réponse à la dépêche Linux a gagné une bataille contre Microsoft. Évalué à 6.
> > que Linux. (rires)
>
> Si Steve fait marrer l'assistance, c'est plutôt
> qu'il est en train de se foutre de notre
> gueule ?
Un peu parano peut être ? C'est une simple plaisanterie sur le fait qu'il est difficile d'être moins cher que gratuit. Faut pas non plus chercher l'attaque frontale de partout...
> Rappelons à Steve que le logiciel gratuit n'est
> pas apparu avec Linux. Que MS utilise donc la
> même stratégie que celle qui lui a si bien
> réussi face au freeware Netscape 4.
Bah, aux dérniéres nouvelles, la part de marché de Microsoft dans les OS Desktop reste autour de 95% donc, quelle que soit leur stratégie, elle semble fonctionner...
[^] # Re: C'est quoi ce délire ? parle pour toi même !
Posté par Dawm . En réponse à la dépêche Linux a gagné une bataille contre Microsoft. Évalué à 3.
[^] # Re: C'est quoi ce délire ? parle pour toi même !
Posté par Dawm . En réponse à la dépêche Linux a gagné une bataille contre Microsoft. Évalué à 10.
Ce qui est clairement vrai et indéniable c'est que l'époque des plantages tous les quarts d'heure de Windows est révolue. Ici j'ai une machine sous XP et l'autre sous Linux, et les 2 se vautrent à peu prés autant c'est à dire une fois par mois, et bien souvent ce n'est pas rééllement la faute du systéme.
Les BSOD, ça n'existe PLUS sous WinXP. Je n'en ai jamais vu depuis que je l'utilise et je ne crois pas qu'on puisse encore en voir à moins de jouer avec des drivers matériels alpha / beta / programmés par mon voisin qui n'y connait rien. Les développeurs windows ne peuvent plus faire n'importe quoi et provoquer ces fameux BSOD.
Par contre, il arrive qu'une task se vautre comme ça arrive sous Linux (en tout cas à moi) et 99% du temps un kill task supprime le probléme.
Bref, je suis d'accord sur le fait que la stabilité n'est plus vraiment un argument en faveur de Linux et comme il a tant d'autres arguments en sa faveur, inutile de radoter sur la stabilité de Win9X
[^] # Re: et gtk ? et tk ? et GnuStep ? et ma soeur ?
Posté par Dawm . En réponse à la dépêche Qt contre MFC. Évalué à 5.
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Dawm . En réponse à la dépêche Qt contre MFC. Évalué à 1.
[^] # Re: perso ...
Posté par Dawm . En réponse à la dépêche Qt contre MFC. Évalué à 0.
[^] # Re: perso ...
Posté par Dawm . En réponse à la dépêche Qt contre MFC. Évalué à 2.
Maintenant si le programmeur est compétent et désire développer pour plusieurs plateformes et/ou en dév collaboratif, il va essaier d'écrire du code plus standard, ou au moins plusieurs versions avec des #define, sinon c'est qu'il ne sait pas programmer.
# Article intéréssant...
Posté par Dawm . En réponse à la dépêche Qt contre MFC. Évalué à 10.
En ce qui concerne le pseudo objet vs object, oui, c'est une évidence mais ce n'est pas vraiment la faute des MFC. Le fait est que toutes les surcouches comme MFC, WTL, ATL sont toutes fortement dépendantes de l'API Win32, qui est massivement écrite en C. Ca a des raisons, en particulier le faite que les bases de l'API n'ont peu ou prou pas changés depuis Windows 3.x, donc à une époque où le C++ n'était pas aussi fortement répandu. Donc d'un côté, c'est bien parce que la compatibilité ascendante est fortement assurée (99% des exe compilés pour win95 tournent sous winXP) mais de l'autre, effectivement, on reste dans un vieux modéle C.
La boucle de messages. Effectivement, elle demande un peu d'apprentissage. Néanmoins je trouve qu'à l'usage elle se révéle assez pratique et fait partie des quelques concepts à bien maitriser pour développer sous Win32. Est elle améliorable, sans doute, est ce vraiment un handicap : je ne pense pas
Au niveau de la simplicité de coding, je ne vois pas de grandes différences...
Si tu veux faire un EditBox en API, tu vas faire un CreateWindow avec les paramétres qui vont bien et voilà.
Sur la doc, certes MSDN n'est pas très facile à maitriser, mais c'est certainement la plus grosse base de documentation sur un OS qui existe. Et tu oublies de parles des newsgroups microsoft.* ou autres ng dans les hiérarchies "classiques" dans lesquels des développeurs experimentés Win32 api foisonnent, voir même des propres développeurs Microsft pour les ng ms.* Je ne peux pas préjuger de la qualité de la doc de Qt ne l'ayant pas lu ni pratiqué, mais honnêtement je ne me souviens pas avoir eu un probléme sans trouver la solution dans les 1 à 2 heures suivantes en win32 API (et c'est encore plus vrai en MFC vu le nombre de sites dédiés).
Les CString sont une daube, aucun doute là dessus. Mais pourquoi ne pas utiliser std::string qui convient dans 95% des cas ?
Tu dis qu'il n'y a pas de ressources dans QT, mais quel autre systéme remplit ce rôle alors ?
Sinon pour moi, le gros avantage de QT c'est avant tout qu'il est multiplateformes.. C'est un réél intêret pour celui qui veut développer un prorgramme graphique à destination de plusieurs OS