Pas d'accord!
J'ai installé Windows ET Linux sur la bécane de ma copine (qui ne connait ni l'un ni l'autre) en me disant que le meilleur moyen d'imposer Linux était de laisser l'alternative et d'attendre...
Sans prétendre que Windows est mieux/moins bien ou quoi que ce soit... le problème est dans ta phrase: "j'ai installé ..."... crois-tu qu'elle aurait pu l'installer elle même? Je crois que c'est là, un des point ou il reste beaucoup d'effort à faire... (aussi bien du côté Win32 d'ailleurs...).
J'ai un peu (et j'utilise encore ;-) utilisé Eclipse, et je dois avouer que venant d'un monde ms (VS6), j'ai trouvé eclipse pas mauvais, le CVS même s'il est curieux a fonctionné sans problème, si ce n'est qu'il est à mon gout bizarement intégré (ce n'est pas le wincvs qui est finalement totalement extérieur, mais ce n'est pas non plus complètement intégré à l'IDE au point de rendre son utilisation transparente).
Du coup je me demandais: les problèmes que tu as eu venait-il d'Eclipse? ou des outils tiers, ou encore d'un manque d'habitude (parce que faut reconnaitre que le temps qu'il faut pour s'adapter à ce monstre est plutôt énorme)?
L'intêret étant que j'en suis resté à de petits projets java (max 3 développeurs, quelques milliers de ligne de code) et j'aimerais savoir s'il est imaginable de l'utiliser pour un plus gros projet que je devrai bientôt commencer? Ou si tu as vraiment connu des trucs dissuasifs?
L'algorithme proposé par Ingo, lui reste de complexité constante quelque soit le nombre de threads (O(1)). Et il semble marcher plutôt bien.
Je me posais quelques questions, il semble évident que pousser à l'extrème le O(1) d'Ingo écrase ce qui existe, mais qu'en est-il avec un nombre de thread restreint (car dans ce cas la complexité théorique n'est plus la seule à compter, mais également le temps d'exécution de l'algo, si un passe de cet algo prend 10ms tandis que l'autre en O(n) prends 1ms... il faut plus de 10 threads pour que cela deviennent interessant)? Est-ce meilleurs que ce qu'il y'a actuellement? nettement meilleurs? En bref, verra-t-on la différence quand on fera autre chose qu'un bench?
Super, tu l'aurais pas provoqué ton stop-screen? (allez juste un peu?).
Stop 0x0000007B or INACCESSIBLE_BOOT_DEVICE
This Stop message, also known as Stop 0x7B, indicates that Windows 2000 lost access to the system partition during the startup process. This error always occurs while the system is starting and cannot be debugged because it generally occurs before the operating system has loaded the debugger.
[-1 parce que HS, y'a pas de scheduler chargé quand on est arrivé que là...;-)]
Posté par tene .
En réponse à la dépêche Qt contre MFC.
Évalué à 10.
Je t'encourage a downloader la version d'evaluation et a lire le tutorial. En quelques heures, tu pourras faire une application Qt.
C'est fait (évidemment ;-), je testerai cela après le boulot!
Cependant, je rajoute quand même quelques précisions sur mes questions:
- les performances: je n'ai pas vu d'application tourné sous Qt, et j'aimerais en voir, je ne parle pas d'un petit exemple, mais d'une "vraie" application.
Bcp de "technologie" sont bluffantes dans les exemples et moins jolie une fois qu'on passe à la réalité (GDI+, DirectX, opengl, etc... si on se limite au graphisme, sont très simple à aborder, mais obtenir un truc réellement performant, demande beaucoup de travail... )
Enfin la question de gestion doc/view, serialization, etc...
Serialization: la base, En MFC tu as une série de conteneur plus ou moins générique: ils sont perfectible, mais ont un avantage: ils sont serializable et serialize leur contenu, pour cela il suffit d'implémenter une ou deux méthodes dans chaque classe. Je n'ai pas trouvé de classe de base serializable commune à tous Qt, faut dire je n'ai fait que passer en vitesse... et réécrire cela pour une application prend du temps...
La gestion MDI de MFC est évidemment reproductible, mais le fait que les MFC offrent d'emblé un framework cohérent et souple pour le faire permet de gagner du temps (30 secondes pour avoir une app de base multi-document, multi-view...).
Le fait d'avoir ou pas cela en QT permettra de gagner ou non un temps précieux (qui sera peut-être perdu avec MFC dans d'autre partie de l'application). En java par exemple rien n'est réellement prévu pour, je me retrouve alors à "ramer" pour avoir une bête application SDI cohérente, la gestion des barres d'outils et des menus est un cauchemar (comparé à ce que je connais en MFC). D'où ma question...
Enfin voilà, je testerai un peu avec Qt dès que j'aurai un peu de temps, l'idée d'avoir quelques choses multi-plateforme me plait assez en fait...
Et finalement: J'ai laisse passer celui-la: bien sur qu'ils jouent dans la meme cour. Le but, c'est de produire une application avec des controles, sous Windows. Qt et les MFC permettent tous les deux d'obtenir ca.
MFC permet beaucoup plus que cela, c'est plus un framework pour applications qu'un framework d'interface graphique, il apporte son lot de contrainte ainsi que ces quelques solutions. SI QT ne propose pas de classes pour gérer le doc/view, aucune solution pour le MDI, pas de serialization, etc. alors MFC est quelque chose d'assez différent de QT, cela ne diminue en rien la qualité de QT, mais cela biaise un peu le débat, on se retrouve à comparer deux choses différentes en ne tenant pas compte de leur différences.
Sous Windows, ce qui permet d'avoir des applications avec contrôle, c'est Win32 (les "widget" MFC sont des contrôle windows, MFC ne fait QUE layer objet entre les deux, il n'implémente pas (plus) grand chose de graphique). Si tu utilises MFC pour avoir des classes au lieu de handle, ce n'est à mon avis pas la bonne idée (y'a mieux...), si tu pars du principe que MFC va te permettre d'avoir un ensemble cohérent entre les données de ton app, le feedback graphique et l'utilisateur, alors tu y es... mais est-ce bien le but de QT? (KDE n'ajoute-t-il pas son lot de classe qui prenne en charge ce que QT ne fait pas?).
Posté par tene .
En réponse à la dépêche Qt contre MFC.
Évalué à 10.
La comparaison QT/MFC est surprenante, je développe avec MFC depuis quelques années, et j'avoue plutôt aimer... mais en lisant l'article, je me dis: en effet, ça peut faire gagner du temps... Ceci dit, ne connaissant pas Qt, je me pose quelques questions:
- la finesse de MFC pour ce qui concerne la gestion fenêtre/GDI est un défaut, en ce qui concerne l'approche objet... mais cela rend MFC relativement rapide et léger (dans un CWnd la classe de base englobant les fenêtre, presque toutes les méthodes sont inlines), qu'en est-il des performances de QT? Je n'ai pas vu tourner d'application Qt sous Win32, sous nux, c'tait des app KDE, plutôt lente, quelqu'un aurait des exemples (compilés)?
- Tu parles du modèle doc/view, tout d'abord, il est parfaitement évitable (par défaut dans le cas d'une application basé sur une boite de dialogue, MFC ne crée rien en rapport avec doc/view) Ensuite qu'est ce que QT propose dans ce domaine? (serialization, gestion MDI, vue multiple, etc...)
- Je suis également surpris, quand tu parles de CString/QString, as-tu regarder le CString de VS.NET?
Il m'a semblé qu'ils ont (enfin) nettoyé leur bordel.
Enfin voilà, pour conclure, je me demande juste si MFC et QT joue bien dans la même cours...
Il me semble que DX est (malheureusement...) encore un peu plus que la SDL... (rien qu'au niveau 3D déjà).
Il me semble aussi que la SDL repose encore sur DX6 pour ce qui est des surfaces d'affichages et qu'au niveau gestion des périphérique d'entrée et sons, c'est encore loin de DX (faut pas oublier que DXShow fait partie de DirectX 8 maintenant).
Ceci dit, est-ce réellement le manque d'un "DirectX" sous nux qui rebute les éditeurs à porter leurs jeux?
[^] # Re: Enfin !
Posté par tene . En réponse à la dépêche Microsoft reconnait Linux comme un concurrent sérieux. Évalué à 0.
J'ai installé Windows ET Linux sur la bécane de ma copine (qui ne connait ni l'un ni l'autre) en me disant que le meilleur moyen d'imposer Linux était de laisser l'alternative et d'attendre...
Sans prétendre que Windows est mieux/moins bien ou quoi que ce soit... le problème est dans ta phrase: "j'ai installé ..."... crois-tu qu'elle aurait pu l'installer elle même? Je crois que c'est là, un des point ou il reste beaucoup d'effort à faire... (aussi bien du côté Win32 d'ailleurs...).
[^] # Re: Quoi Emacs ?
Posté par tene . En réponse à la dépêche Des nouvelles d'Eclipse. Évalué à 5.
Du coup je me demandais: les problèmes que tu as eu venait-il d'Eclipse? ou des outils tiers, ou encore d'un manque d'habitude (parce que faut reconnaitre que le temps qu'il faut pour s'adapter à ce monstre est plutôt énorme)?
L'intêret étant que j'en suis resté à de petits projets java (max 3 développeurs, quelques milliers de ligne de code) et j'aimerais savoir s'il est imaginable de l'utiliser pour un plus gros projet que je devrai bientôt commencer? Ou si tu as vraiment connu des trucs dissuasifs?
[^] # Re: Ordonnanceur?
Posté par tene . En réponse à la dépêche Les promesses de la Native POSIX Threading Library et du prochain Kernel 2.6. Évalué à 10.
Je me posais quelques questions, il semble évident que pousser à l'extrème le O(1) d'Ingo écrase ce qui existe, mais qu'en est-il avec un nombre de thread restreint (car dans ce cas la complexité théorique n'est plus la seule à compter, mais également le temps d'exécution de l'algo, si un passe de cet algo prend 10ms tandis que l'autre en O(n) prends 1ms... il faut plus de 10 threads pour que cela deviennent interessant)? Est-ce meilleurs que ce qu'il y'a actuellement? nettement meilleurs? En bref, verra-t-on la différence quand on fera autre chose qu'un bench?
[^] # Re: Ordonnanceur?
Posté par tene . En réponse à la dépêche Les promesses de la Native POSIX Threading Library et du prochain Kernel 2.6. Évalué à 10.
Stop 0x0000007B or INACCESSIBLE_BOOT_DEVICE
This Stop message, also known as Stop 0x7B, indicates that Windows 2000 lost access to the system partition during the startup process. This error always occurs while the system is starting and cannot be debugged because it generally occurs before the operating system has loaded the debugger.
[-1 parce que HS, y'a pas de scheduler chargé quand on est arrivé que là...;-)]
[^] # Re: Interressant...
Posté par tene . En réponse à la dépêche Qt contre MFC. Évalué à 10.
C'est fait (évidemment ;-), je testerai cela après le boulot!
Cependant, je rajoute quand même quelques précisions sur mes questions:
- les performances: je n'ai pas vu d'application tourné sous Qt, et j'aimerais en voir, je ne parle pas d'un petit exemple, mais d'une "vraie" application.
Bcp de "technologie" sont bluffantes dans les exemples et moins jolie une fois qu'on passe à la réalité (GDI+, DirectX, opengl, etc... si on se limite au graphisme, sont très simple à aborder, mais obtenir un truc réellement performant, demande beaucoup de travail... )
Enfin la question de gestion doc/view, serialization, etc...
Serialization: la base, En MFC tu as une série de conteneur plus ou moins générique: ils sont perfectible, mais ont un avantage: ils sont serializable et serialize leur contenu, pour cela il suffit d'implémenter une ou deux méthodes dans chaque classe. Je n'ai pas trouvé de classe de base serializable commune à tous Qt, faut dire je n'ai fait que passer en vitesse... et réécrire cela pour une application prend du temps...
La gestion MDI de MFC est évidemment reproductible, mais le fait que les MFC offrent d'emblé un framework cohérent et souple pour le faire permet de gagner du temps (30 secondes pour avoir une app de base multi-document, multi-view...).
Le fait d'avoir ou pas cela en QT permettra de gagner ou non un temps précieux (qui sera peut-être perdu avec MFC dans d'autre partie de l'application). En java par exemple rien n'est réellement prévu pour, je me retrouve alors à "ramer" pour avoir une bête application SDI cohérente, la gestion des barres d'outils et des menus est un cauchemar (comparé à ce que je connais en MFC). D'où ma question...
Enfin voilà, je testerai un peu avec Qt dès que j'aurai un peu de temps, l'idée d'avoir quelques choses multi-plateforme me plait assez en fait...
Et finalement:
J'ai laisse passer celui-la: bien sur qu'ils jouent dans la meme cour. Le but, c'est de produire une application avec des controles, sous Windows. Qt et les MFC permettent tous les deux d'obtenir ca.
MFC permet beaucoup plus que cela, c'est plus un framework pour applications qu'un framework d'interface graphique, il apporte son lot de contrainte ainsi que ces quelques solutions. SI QT ne propose pas de classes pour gérer le doc/view, aucune solution pour le MDI, pas de serialization, etc. alors MFC est quelque chose d'assez différent de QT, cela ne diminue en rien la qualité de QT, mais cela biaise un peu le débat, on se retrouve à comparer deux choses différentes en ne tenant pas compte de leur différences.
Sous Windows, ce qui permet d'avoir des applications avec contrôle, c'est Win32 (les "widget" MFC sont des contrôle windows, MFC ne fait QUE layer objet entre les deux, il n'implémente pas (plus) grand chose de graphique). Si tu utilises MFC pour avoir des classes au lieu de handle, ce n'est à mon avis pas la bonne idée (y'a mieux...), si tu pars du principe que MFC va te permettre d'avoir un ensemble cohérent entre les données de ton app, le feedback graphique et l'utilisateur, alors tu y es... mais est-ce bien le but de QT? (KDE n'ajoute-t-il pas son lot de classe qui prenne en charge ce que QT ne fait pas?).
# Interressant...
Posté par tene . En réponse à la dépêche Qt contre MFC. Évalué à 10.
- la finesse de MFC pour ce qui concerne la gestion fenêtre/GDI est un défaut, en ce qui concerne l'approche objet... mais cela rend MFC relativement rapide et léger (dans un CWnd la classe de base englobant les fenêtre, presque toutes les méthodes sont inlines), qu'en est-il des performances de QT? Je n'ai pas vu tourner d'application Qt sous Win32, sous nux, c'tait des app KDE, plutôt lente, quelqu'un aurait des exemples (compilés)?
- Tu parles du modèle doc/view, tout d'abord, il est parfaitement évitable (par défaut dans le cas d'une application basé sur une boite de dialogue, MFC ne crée rien en rapport avec doc/view) Ensuite qu'est ce que QT propose dans ce domaine? (serialization, gestion MDI, vue multiple, etc...)
- Je suis également surpris, quand tu parles de CString/QString, as-tu regarder le CString de VS.NET?
Il m'a semblé qu'ils ont (enfin) nettoyé leur bordel.
Enfin voilà, pour conclure, je me demande juste si MFC et QT joue bien dans la même cours...
[^] # Re: SDL
Posté par tene . En réponse à la dépêche Wrapper DirectX 8 -> OpenGL opensource. Évalué à 7.
Il me semble aussi que la SDL repose encore sur DX6 pour ce qui est des surfaces d'affichages et qu'au niveau gestion des périphérique d'entrée et sons, c'est encore loin de DX (faut pas oublier que DXShow fait partie de DirectX 8 maintenant).
Ceci dit, est-ce réellement le manque d'un "DirectX" sous nux qui rebute les éditeurs à porter leurs jeux?