Windiws Longhorn: le C n est t'il plus le langage de prédilection de programmation pour atteindre le systéme ?
53 réponses
Nospam999
Bonjour bonsoir,
Dans Pc Expert de septembre 2003 Olivier Gaussin dit à propos de .Net "Le
framework repose sur Windows mais on n'est pas loin d'arriver à la situation
inverse , où Windows reposera sur le framework. En effet, le prochain
système d'exploitation de Microsoft, Longhorn, qui n'arrivera pas avant
2004, officialisera . Net comme API dans certains domaines. Exit les Api
Win32: Il faudra nécessairement passer par .Net pour accéder au service du
systèmes"
Cela me fait peur. En effet, je commence à faire de la programmation sous
Windows avec du c avec les Api 32 .
1- Avez vous des informations plus précises ?
2- Est ce vrai ?
3- Dois je arrêter et changer de système si je veux utiliser le C ?
Merci pour de répondre à un véritable débutant.
P.S: 1- J'ai fait une citation un peu longue mais c'était uniquement pour
être
clair. Milles excuses si cela peut gêner quelqu'un.
2- On m'a dit que le cross posting c'est mal: je cherche simplement à
"toucher des populations différentes ( c'est important pour moi...car je
sens que j'y passe du temps) c'est promis je ne recommencerai plus.....
>> Bon précisons donc d'abord que ".NET framework" est un environnement >> de travail pour faire de l'appli réseau ou déployable réseau (et à >> vocation multiplatform) et pas spécialement concu pour faire de >> l'appli native 32. > Multi-platforme...hahaha, la bonne blague....Ca fait 2 ans que ca > tourne...que sous Windows, et encore, pas > complètement sous Win64 Itanium.
Y'a le projeyt Mono pour faire tourner ça sous Linux.
Autrement dit, environ le quart a été porté sous Linux....et même pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...
David
"Thierry" <yarglah@com.invalid> a écrit dans le message de news:XnF93F7781DEBF59pouletetcetc@213.228.0.138...
Bonjour,
David Scrève a écrit :
>> Bon précisons donc d'abord que ".NET framework" est un environnement
>> de travail pour faire de l'appli réseau ou déployable réseau (et à
>> vocation multiplatform) et pas spécialement concu pour faire de
>> l'appli native 32.
> Multi-platforme...hahaha, la bonne blague....Ca fait 2 ans que ca
> tourne...que sous Windows, et encore, pas
> complètement sous Win64 Itanium.
Y'a le projeyt Mono pour faire tourner ça sous Linux.
Autrement dit, environ le quart a été porté sous Linux....et même pas par Microsoft....Pas mal comme
effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...
>> Bon précisons donc d'abord que ".NET framework" est un environnement >> de travail pour faire de l'appli réseau ou déployable réseau (et à >> vocation multiplatform) et pas spécialement concu pour faire de >> l'appli native 32. > Multi-platforme...hahaha, la bonne blague....Ca fait 2 ans que ca > tourne...que sous Windows, et encore, pas > complètement sous Win64 Itanium.
Y'a le projeyt Mono pour faire tourner ça sous Linux.
Autrement dit, environ le quart a été porté sous Linux....et même pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...
David
Ambassadeur Kosh wrote:
> "...expliquant comment .NET va remplacer Visual C++, et dans quelle mesures
ben ça va se passer comme ça.
Démarrer / Paramètres / Panneaux de configuration / Ajouter Supprimer / MSDN Démarrer / Paramètres / Panneaux de configuration / Ajouter Supprimer / Visual Studio 6.0 / Supprimer Installer Visual Studio .Net 2003 Installer MSDN .Net Démarrer / Programmes / MVS .Net 2003 / Microsoft Visual Studio .Net 2003
dans quelles mesures : selon qu'il y aura assez de place sur le disque ou que la machine trainera pas trop son boulet.
Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu d'optimisation, une bonne partie du framework (sans winforms), c'est plutôt prometteur je trouve, maintenant c'est clair que le projet est jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6 mois.
.et même pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...
Les windows form, bien que sympathique, sont très fort mappé sur Windows, donc un portage revient à réécrire une bonne partie de windows :-/
Pour les gui, il semble que le projet le plus prometteur soit #WT un port de SWT. Ce n'est pas encore super utilisable, mais ça vient.
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela comme une solution faite pour être portable, mais plutôt comme une plate-forme pouvant être portable si on fait attention. A l'image du C/C++ portable si on utilise les libs qui vont bien... l'avantage évidemment est que le framework .NET couvre bcp plus de domaines que la libc ou la STL C++.
Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu
d'optimisation, une bonne partie du framework (sans winforms), c'est
plutôt prometteur je trouve, maintenant c'est clair que le projet est
jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6
mois.
.et même
pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux
faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas
en natif...
Les windows form, bien que sympathique, sont très fort mappé sur
Windows, donc un portage revient à réécrire une bonne partie de windows
:-/
Pour les gui, il semble que le projet le plus prometteur soit #WT un
port de SWT. Ce n'est pas encore super utilisable, mais ça vient.
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela
comme une solution faite pour être portable, mais plutôt comme une
plate-forme pouvant être portable si on fait attention. A l'image du
C/C++ portable si on utilise les libs qui vont bien... l'avantage
évidemment est que le framework .NET couvre bcp plus de domaines que la
libc ou la STL C++.
Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu d'optimisation, une bonne partie du framework (sans winforms), c'est plutôt prometteur je trouve, maintenant c'est clair que le projet est jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6 mois.
.et même pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...
Les windows form, bien que sympathique, sont très fort mappé sur Windows, donc un portage revient à réécrire une bonne partie de windows :-/
Pour les gui, il semble que le projet le plus prometteur soit #WT un port de SWT. Ce n'est pas encore super utilisable, mais ça vient.
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela comme une solution faite pour être portable, mais plutôt comme une plate-forme pouvant être portable si on fait attention. A l'image du C/C++ portable si on utilise les libs qui vont bien... l'avantage évidemment est que le framework .NET couvre bcp plus de domaines que la libc ou la STL C++.
Marre du spam wrote: > Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu d'optimisation, une bonne partie du framework (sans winforms), c'est plutôt prometteur je trouve, maintenant c'est clair que le projet est jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6 mois.
Donc, d'un point de vue production, ce n'est pas portable....
> .et même > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux > faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas > en natif...
Les windows form, bien que sympathique, sont très fort mappé sur Windows, donc un portage revient à réécrire une bonne partie de windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela comme une solution faite pour être portable, mais plutôt comme une plate-forme pouvant être portable si on fait attention. A l'image du C/C++ portable si on utilise les libs qui vont bien... l'avantage évidemment est que le framework .NET couvre bcp plus de domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ? J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
David
<poubelle@alrj.org> a écrit dans le message de news:258_2003_205053_327455588_MYOE@news.free.fr...
Marre du spam wrote:
> Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu
d'optimisation, une bonne partie du framework (sans winforms), c'est
plutôt prometteur je trouve, maintenant c'est clair que le projet est
jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6
mois.
Donc, d'un point de vue production, ce n'est pas portable....
> .et même
> pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux
> faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas
> en natif...
Les windows form, bien que sympathique, sont très fort mappé sur
Windows, donc un portage revient à réécrire une bonne partie de windows
:-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela
comme une solution faite pour être portable, mais plutôt comme une
plate-forme pouvant être portable si on fait attention. A l'image du
C/C++ portable si on utilise les libs qui vont bien... l'avantage
évidemment est que le framework .NET couvre bcp plus de domaines que la
libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable
plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que
C++ dans chacun des domaines existants ?
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser
sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Marre du spam wrote: > Autrement dit, environ le quart a été porté sous Linux...
Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu d'optimisation, une bonne partie du framework (sans winforms), c'est plutôt prometteur je trouve, maintenant c'est clair que le projet est jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6 mois.
Donc, d'un point de vue production, ce n'est pas portable....
> .et même > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux > faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas > en natif...
Les windows form, bien que sympathique, sont très fort mappé sur Windows, donc un portage revient à réécrire une bonne partie de windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....
Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela comme une solution faite pour être portable, mais plutôt comme une plate-forme pouvant être portable si on fait attention. A l'image du C/C++ portable si on utilise les libs qui vont bien... l'avantage évidemment est que le framework .NET couvre bcp plus de domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ? J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
David
Ambassadeur Kosh
> mdr! excellent, j'aime bcp ;)
merci. j'espere que l'occasion de retourner le compliment se présentera :)
> mdr! excellent, j'aime bcp ;)
merci. j'espere que l'occasion de retourner le compliment se présentera :)
merci. j'espere que l'occasion de retourner le compliment se présentera :)
Thierry
Bonjour,
David Scrève a écrit :
Sans vouloir troller, quand on pousse la réflexion un peu plus, on se dit qu'il faudrait mieux changer d'OS. Ce que je fais derechef, d'ailleurs (adieu monde cruel).
C'est clair qu'en matière de Framework, Cocoa et PowerPlant ont l'air plutot excitants....
Je ne le trouve pas mal celui de .Net. J'y ai trouvé quelques resemblances avec celui de BeOS (au niveau GUI).
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Bonjour,
David Scrève a écrit :
Sans vouloir troller, quand on pousse la réflexion un peu plus, on se
dit qu'il faudrait mieux changer d'OS.
Ce que je fais derechef, d'ailleurs (adieu monde cruel).
C'est clair qu'en matière de Framework, Cocoa et PowerPlant ont
l'air plutot excitants....
Je ne le trouve pas mal celui de .Net. J'y ai trouvé quelques resemblances
avec celui de BeOS (au niveau GUI).
--
"MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Sans vouloir troller, quand on pousse la réflexion un peu plus, on se dit qu'il faudrait mieux changer d'OS. Ce que je fais derechef, d'ailleurs (adieu monde cruel).
C'est clair qu'en matière de Framework, Cocoa et PowerPlant ont l'air plutot excitants....
Je ne le trouve pas mal celui de .Net. J'y ai trouvé quelques resemblances avec celui de BeOS (au niveau GUI).
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
adebaene
"David Scrève" <Marre du spam> wrote in message news:<3f66175d$0$20644$...
plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ?
Ca, ce serait le boulot du comité de normalisation du C++, pas de Microsoft. Si tu tiens vraiement à poser la question sur c.l.c.++.m et supporter le flamewar qui va suivre, libre à toi :-). Ceci dit, je ne pense pas que ce soit le boulot ni du C++ ni de MS de fournir un GUI portable.
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents. - Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Arnaud
"David Scrève" <Marre du spam> wrote in message news:<3f66175d$0$20644$626a54ce@news.free.fr>...
plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que
C++ dans chacun des domaines existants ?
Ca, ce serait le boulot du comité de normalisation du C++, pas de
Microsoft. Si tu tiens vraiement à poser la question sur c.l.c.++.m et
supporter le flamewar qui va suivre, libre à toi :-). Ceci dit, je ne
pense pas que ce soit le boulot ni du C++ ni de MS de fournir un GUI
portable.
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser
sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.
"David Scrève" <Marre du spam> wrote in message news:<3f66175d$0$20644$...
plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ?
Ca, ce serait le boulot du comité de normalisation du C++, pas de Microsoft. Si tu tiens vraiement à poser la question sur c.l.c.++.m et supporter le flamewar qui va suivre, libre à toi :-). Ceci dit, je ne pense pas que ce soit le boulot ni du C++ ni de MS de fournir un GUI portable.
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents. - Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Arnaud
Arnold McDonald \(AMcD\)
Arnaud Debaene wrote:
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Cela dit, c'est vrai que le code C++ écrit par des gars qui veulement démontrer qu'ils ont bien compris les templates, le multi-héritage, la surcharge et autres joyeusetés est tout simplement illisible. Point trop n'en faut non plus.
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
Arnaud
-- AMcD - http://arnold.mcdonald.free.fr/
"Bon alors j'vous rappelle les règles : vous pouvez pas quitter la première base avant d'avoir vidé une bière, chaque point marqué : une bière, vous videz une bière à la fin des tours de frappe impairs et à la quatrième manche, tournée générale" - ça va, ça va, on sait comment jouer au softball ! (Les Simpson - Homer la Foudre)
Arnaud Debaene wrote:
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Cela dit, c'est
vrai que le code C++ écrit par des gars qui veulement démontrer qu'ils ont
bien compris les templates, le multi-héritage, la surcharge et autres
joyeusetés est tout simplement illisible. Point trop n'en faut non plus.
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
Arnaud
--
AMcD - http://arnold.mcdonald.free.fr/
"Bon alors j'vous rappelle les règles : vous pouvez pas quitter la première
base avant d'avoir vidé une bière, chaque point marqué : une bière, vous
videz une bière à la fin des tours de frappe impairs et à la quatrième
manche, tournée générale"
- ça va, ça va, on sait comment jouer au softball ! (Les Simpson - Homer la
Foudre)
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Cela dit, c'est vrai que le code C++ écrit par des gars qui veulement démontrer qu'ils ont bien compris les templates, le multi-héritage, la surcharge et autres joyeusetés est tout simplement illisible. Point trop n'en faut non plus.
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
Arnaud
-- AMcD - http://arnold.mcdonald.free.fr/
"Bon alors j'vous rappelle les règles : vous pouvez pas quitter la première base avant d'avoir vidé une bière, chaque point marqué : une bière, vous videz une bière à la fin des tours de frappe impairs et à la quatrième manche, tournée générale" - ça va, ça va, on sait comment jouer au softball ! (Les Simpson - Homer la Foudre)
Marre du spam wrote:
> Marre du spam wrote: > > Autrement dit, environ le quart a été porté sous Linux... > > Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un > peu d'optimisation, une bonne partie du framework (sans winforms), > c'est plutôt prometteur je trouve, maintenant c'est clair que le > projet est jeune, faut pas s'attendre à qqch capable de tourner en > prod dans 6 > mois. Donc, d'un point de vue production, ce n'est pas portable....
Bah, je suis plus patient que toi ;)
Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce que .NET pour windows est déjà prêt? perso, je me lancerais pas encore les yeux fermé dans un projet .NET... c'est humain: si c'est professionnel, je reste dans ce que je connais et crois maitriser un peu ;)
> > .et même > > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut > > mieux faire. En plus, les Windows Forms tournent au dessus de > > Wine, meme pas en natif... > > Les windows form, bien que sympathique, sont très fort mappé sur > Windows, donc un portage revient à réécrire une bonne partie de > windows :-/ Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....
Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et un not, l'informatique n'a pas avancé;)
Le fait est que .NET doit bien faire appel à windows, puisque c'est windows qui fournit les interfaces graphiques (l'os est conçu comme cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit rien et X non plus, il faut donc faire quelques choses au dessus, soit tu t'arranges pour que ce quelques choses ressemblent aux services offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger pour que le comportement de winforms restent cohérent au dessus d'une couche ne fournissant pas le même genre de service, ou en tous cas pas de la même façon. Cependant, mais on a encore que très peu d'info, il semblerait que le futur windows change cela en fournissant un autre service de gestion de GUI... ptêt l'occasion d'effacer quelques conneries de winforms?
Cette approche a tout de même un avantage: tu as la rapidité du natif (ce que java n'a pas, swing est une horreur!) et une abstractoin beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32. Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement une "belle" IHM, et si tu dois quand même aller voir ta pompe à message, c'est possible...
Maintenant, je me demandaisi, tu développes beaucoup de produit GUI portable? dans quel langage? en dehors des IDE java et de quelques outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le cas pour toi?
> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas > cela comme une solution faite pour être portable, mais plutôt comme > une plate-forme pouvant être portable si on fait attention. A > l'image du C/C++ portable si on utilise les libs qui vont bien... > l'avantage évidemment est que le framework .NET couvre bcp plus de > domaines que la libc ou la STL C++. La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ?
Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre que très peu de services, et vu le temps que ça met à évoluer, je peux comprendre qu'une boite telle que ms, préfère faire son truc à elle... (d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne, portable???)
Concernant java, il faut à nouveau séparer le langage de la plate-forme, concernant le langage, c'est plus une question de gout (je préfère le C# de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour l'autre). Concernant la plate-forme, elles ont des approches souvent un peu différentes, je préfère également travailllé avec .NET, et .NET offre certains avantage (versionning, déploiement, gestion des resources, etc...) comme il doit avoir également ses défauts...
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de développement encore fait en C (voir des trucs encore pire ;), regarde le temps que met une norme pour évoluer, combien de siècle crois-tu qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe quel "existant parfaitement évolutif" ? Même java est mou, c'est d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en train d'être normalisé... le java existe depuis beaucoup plus longtemps et le langage n'a pas évolué, on en parle, pour le futur java 1.5, mais... ça vient quand?
Il faut aussi tenir compte de la complexité du C++, comme le soulève très justement Arnaud, il est plus simple de programmer (mal) en C# qu'en C++... et je pense qu'il est plus simple de programmer correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur que tu ne pourras pas faire en C#...
> Marre du spam wrote:
> > Autrement dit, environ le quart a été porté sous Linux...
>
> Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un
> peu d'optimisation, une bonne partie du framework (sans winforms),
> c'est plutôt prometteur je trouve, maintenant c'est clair que le
> projet est jeune, faut pas s'attendre à qqch capable de tourner en
> prod dans 6
> mois.
Donc, d'un point de vue production, ce n'est pas portable....
Bah, je suis plus patient que toi ;)
Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce
que .NET pour windows est déjà prêt? perso, je me lancerais pas encore
les yeux fermé dans un projet .NET... c'est humain: si c'est
professionnel, je reste dans ce que je connais et crois maitriser un
peu ;)
> > .et même
> > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut
> > mieux faire. En plus, les Windows Forms tournent au dessus de
> > Wine, meme pas en natif...
>
> Les windows form, bien que sympathique, sont très fort mappé sur
> Windows, donc un portage revient à réécrire une bonne partie de
> windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un
système existant....
Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et
un not, l'informatique n'a pas avancé;)
Le fait est que .NET doit bien faire appel à windows, puisque c'est
windows qui fournit les interfaces graphiques (l'os est conçu comme
cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas
vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit
rien et X non plus, il faut donc faire quelques choses au dessus, soit
tu t'arranges pour que ce quelques choses ressemblent aux services
offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger
pour que le comportement de winforms restent cohérent au dessus d'une
couche ne fournissant pas le même genre de service, ou en tous cas pas
de la même façon. Cependant, mais on a encore que très peu d'info, il
semblerait que le futur windows change cela en fournissant un autre
service de gestion de GUI... ptêt l'occasion d'effacer quelques
conneries de winforms?
Cette approche a tout de même un avantage: tu as la rapidité du natif
(ce que java n'a pas, swing est une horreur!) et une abstractoin
beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32.
Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement
une "belle" IHM, et si tu dois quand même aller voir ta pompe à
message, c'est possible...
Maintenant, je me demandaisi, tu développes beaucoup de produit GUI
portable? dans quel langage? en dehors des IDE java et de quelques
outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le
cas pour toi?
> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas
> cela comme une solution faite pour être portable, mais plutôt comme
> une plate-forme pouvant être portable si on fait attention. A
> l'image du C/C++ portable si on utilise les libs qui vont bien...
> l'avantage évidemment est que le framework .NET couvre bcp plus de
> domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une
lib C++ de GUI qui soit portable plutot que de faire une autre
surcouche qui n'est pas vraiment portable et qui fait moins bien que
Java et que C++ dans chacun des domaines existants ?
Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre
que très peu de services, et vu le temps que ça met à évoluer, je peux
comprendre qu'une boite telle que ms, préfère faire son truc à elle...
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne,
portable???)
Concernant java, il faut à nouveau séparer le langage de la plate-forme,
concernant le langage, c'est plus une question de gout (je préfère le C#
de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour
l'autre). Concernant la plate-forme, elles ont des approches souvent un
peu différentes, je préfère également travailllé avec .NET, et .NET
offre certains avantage (versionning, déploiement, gestion des
resources, etc...) comme il doit avoir également ses défauts...
J'ai un peu l'impression que le marketing a fait dépenser pas mal
d'énergie n'importe comment au lieu de se baser sur un existant
parfaitement évolutif qui ne demandait qu'à évoluer...
Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de
développement encore fait en C (voir des trucs encore pire ;), regarde
le temps que met une norme pour évoluer, combien de siècle crois-tu
qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe
quel "existant parfaitement évolutif" ? Même java est mou, c'est
d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre
par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en
train d'être normalisé... le java existe depuis beaucoup plus longtemps
et le langage n'a pas évolué, on en parle, pour le futur java 1.5,
mais... ça vient quand?
Il faut aussi tenir compte de la complexité du C++, comme le soulève
très justement Arnaud, il est plus simple de programmer (mal) en C#
qu'en C++... et je pense qu'il est plus simple de programmer
correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur
que tu ne pourras pas faire en C#...
> Marre du spam wrote: > > Autrement dit, environ le quart a été porté sous Linux... > > Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un > peu d'optimisation, une bonne partie du framework (sans winforms), > c'est plutôt prometteur je trouve, maintenant c'est clair que le > projet est jeune, faut pas s'attendre à qqch capable de tourner en > prod dans 6 > mois. Donc, d'un point de vue production, ce n'est pas portable....
Bah, je suis plus patient que toi ;)
Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce que .NET pour windows est déjà prêt? perso, je me lancerais pas encore les yeux fermé dans un projet .NET... c'est humain: si c'est professionnel, je reste dans ce que je connais et crois maitriser un peu ;)
> > .et même > > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut > > mieux faire. En plus, les Windows Forms tournent au dessus de > > Wine, meme pas en natif... > > Les windows form, bien que sympathique, sont très fort mappé sur > Windows, donc un portage revient à réécrire une bonne partie de > windows :-/ Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....
Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et un not, l'informatique n'a pas avancé;)
Le fait est que .NET doit bien faire appel à windows, puisque c'est windows qui fournit les interfaces graphiques (l'os est conçu comme cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit rien et X non plus, il faut donc faire quelques choses au dessus, soit tu t'arranges pour que ce quelques choses ressemblent aux services offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger pour que le comportement de winforms restent cohérent au dessus d'une couche ne fournissant pas le même genre de service, ou en tous cas pas de la même façon. Cependant, mais on a encore que très peu d'info, il semblerait que le futur windows change cela en fournissant un autre service de gestion de GUI... ptêt l'occasion d'effacer quelques conneries de winforms?
Cette approche a tout de même un avantage: tu as la rapidité du natif (ce que java n'a pas, swing est une horreur!) et une abstractoin beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32. Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement une "belle" IHM, et si tu dois quand même aller voir ta pompe à message, c'est possible...
Maintenant, je me demandaisi, tu développes beaucoup de produit GUI portable? dans quel langage? en dehors des IDE java et de quelques outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le cas pour toi?
> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas > cela comme une solution faite pour être portable, mais plutôt comme > une plate-forme pouvant être portable si on fait attention. A > l'image du C/C++ portable si on utilise les libs qui vont bien... > l'avantage évidemment est que le framework .NET couvre bcp plus de > domaines que la libc ou la STL C++. La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que C++ dans chacun des domaines existants ?
Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre que très peu de services, et vu le temps que ça met à évoluer, je peux comprendre qu'une boite telle que ms, préfère faire son truc à elle... (d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne, portable???)
Concernant java, il faut à nouveau séparer le langage de la plate-forme, concernant le langage, c'est plus une question de gout (je préfère le C# de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour l'autre). Concernant la plate-forme, elles ont des approches souvent un peu différentes, je préfère également travailllé avec .NET, et .NET offre certains avantage (versionning, déploiement, gestion des resources, etc...) comme il doit avoir également ses défauts...
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...
Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de développement encore fait en C (voir des trucs encore pire ;), regarde le temps que met une norme pour évoluer, combien de siècle crois-tu qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe quel "existant parfaitement évolutif" ? Même java est mou, c'est d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en train d'être normalisé... le java existe depuis beaucoup plus longtemps et le langage n'a pas évolué, on en parle, pour le futur java 1.5, mais... ça vient quand?
Il faut aussi tenir compte de la complexité du C++, comme le soulève très justement Arnaud, il est plus simple de programmer (mal) en C# qu'en C++... et je pense qu'il est plus simple de programmer correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur que tu ne pourras pas faire en C#...
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ?
Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
Yep.
Arnaud
Arnold McDonald (AMcD) wrote:
Arnaud Debaene wrote:
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ?
Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans l'absolu, ce ne sont pas de bonnes raison mais il faut rester pragmatique : - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ compétents.
Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ?
Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent faire du C++ font en fait du C.
Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.
