Bon je vais peut-être me faire gronder en posant ces questions qui à mon
avis ont déjà été posé, mais je les pose quand même car j'ai pas trouvé de
réponses :(
1. Faut-il un moteur spécifique pour faire tourner des applications C# comme
avec les applications Java ? Ou alors est-ce que les applications C#
tournent sans aucun problème sous Win9X, Win2000, et XP ?
2. Est-ce vraiment plus rapide que le C++ pour développer des applications
Windows ?
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant
qu'à faire autant demander..)
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec C++
? Et la vitesse d'exécution ?
5. Pouvez-vous me conseiller un bon bouquin en français pour développer des
applications Windows en C#? (je connais très très bien le C-UNIX, le C++, et
pas vraiment les API WIN32)
Merci de votre aide à tous :) J'hésite à apprendre le C++ avec l'api Win32
ou directement passer au C#... sachant que je veux développer des
applications Windows ;)
1. Faut-il un moteur spécifique pour faire tourner des applications C# comme
avec les applications Java ? Ou alors est-ce que les applications C# tournent sans aucun problème sous Win9X, Win2000, et XP ?
Runtime .NET Framework (~11Mb à downloader...)
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Oui. comparable à VisualBasic pour ça
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant qu'à faire autant demander..)
DirectX oui depuis la version 9. OpenGl via http://csgl.sourceforge.net/
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec C++
"Hello World" nécessite les 11Mb du FrameWork .NET...
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif. -- Philippe Guglielmetti - www.dynabits.com
Jean-Marc Bourguet
"Philippe Guglielmetti" writes:
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Oui. comparable à VisualBasic pour ça
Est-ce que tu as repondu a la question "est-ce vraiment plus rapide que le C++ pour developper des interfaces graphiques sous Windows" ou a la question telle qu'ecrite ci-dessus?
Si c'est bien a la question telle que posee, quels sont les facteurs qui influencent le developpement plus rapide de la partie non interface graphique des applications?
Si c'est bien a ma reformulation que tu as repondu, a quels autres framework graphiques compares-tu?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
2. Est-ce vraiment plus rapide que le C++ pour développer des applications
Windows ?
Oui. comparable à VisualBasic pour ça
Est-ce que tu as repondu a la question "est-ce vraiment plus rapide
que le C++ pour developper des interfaces graphiques sous Windows" ou
a la question telle qu'ecrite ci-dessus?
Si c'est bien a la question telle que posee, quels sont les facteurs
qui influencent le developpement plus rapide de la partie non
interface graphique des applications?
Si c'est bien a ma reformulation que tu as repondu, a quels autres
framework graphiques compares-tu?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Oui. comparable à VisualBasic pour ça
Est-ce que tu as repondu a la question "est-ce vraiment plus rapide que le C++ pour developper des interfaces graphiques sous Windows" ou a la question telle qu'ecrite ci-dessus?
Si c'est bien a la question telle que posee, quels sont les facteurs qui influencent le developpement plus rapide de la partie non interface graphique des applications?
Si c'est bien a ma reformulation que tu as repondu, a quels autres framework graphiques compares-tu?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Martinez Jerome
Philippe Guglielmetti wrote:
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
Les bytecode ne sont pas forcement plus lent que du natif (voir démo qui m'a été faite ici un jour sur le bytecode de Java, j'ai appris la lecon... :) )
Philippe Guglielmetti wrote:
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
Les bytecode ne sont pas forcement plus lent que du natif
(voir démo qui m'a été faite ici un jour sur le bytecode de Java, j'ai
appris la lecon... :) )
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
Les bytecode ne sont pas forcement plus lent que du natif (voir démo qui m'a été faite ici un jour sur le bytecode de Java, j'ai appris la lecon... :) )
Loïc Joly
TigrouMeow wrote:
Hello ;)
Bon je vais peut-être me faire gronder en posant ces questions qui à mon avis ont déjà été posé, mais je les pose quand même car j'ai pas trouvé de réponses :(
Le critère de grondage est plus le hors sujet que la répétition de questions, même s'il ne faut pas exagérer.
1. Faut-il un moteur spécifique pour faire tourner des applications C# comme avec les applications Java ? Ou alors est-ce que les applications C# tournent sans aucun problème sous Win9X, Win2000, et XP ? Moteur spécifique. Qui a toutes les chances d'être inclus par défaut
dans les prochains windows.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ? Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Si la question est : Est-il plus rapide de développer une appli d'IHM en C#/.NET framework qu'en C++/Bibliothèque qui va bien (wxWindows, QT...), la réponse est bien plus difficile, et polémique. Un autre élément est aussi de savoir si à terme on veut pouvoir tourner sur des plates-formes non windows.
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant qu'à faire autant demander..) Probablement, mais je ne sais pas à quel point c'est fait proprement ou
au chausse pied.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec C++ ? Aucune idée.
Et la vitesse d'exécution ? Ca doit dépendre du type d'application. Pour de l'IHM, on ne vera
peut-être pas de différence. Pour des applications intensives en calcul, on risque de voir des différence non négligeables avec par exemple du C++ utilisant des templates à bon escient.
5. Pouvez-vous me conseiller un bon bouquin en français pour développer des applications Windows en C#? (je connais très très bien le C-UNIX, le C++, et pas vraiment les API WIN32) Non, désolé.
Merci de votre aide à tous :) J'hésite à apprendre le C++ avec l'api Win32 ou directement passer au C#... sachant que je veux développer des applications Windows ;)
Je pense qu'utiliser directement l'API Win32 est une perte de temps importante. Mais C# + .NET framework n'est pas la seule alternative.
-- Loïc
TigrouMeow wrote:
Hello ;)
Bon je vais peut-être me faire gronder en posant ces questions qui à mon
avis ont déjà été posé, mais je les pose quand même car j'ai pas trouvé de
réponses :(
Le critère de grondage est plus le hors sujet que la répétition de
questions, même s'il ne faut pas exagérer.
1. Faut-il un moteur spécifique pour faire tourner des applications C# comme
avec les applications Java ? Ou alors est-ce que les applications C#
tournent sans aucun problème sous Win9X, Win2000, et XP ?
Moteur spécifique. Qui a toutes les chances d'être inclus par défaut
dans les prochains windows.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications
Windows ?
Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les
efforts marketing (récupération de code sur site web...) et fait pour C#
ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le
C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps
passé à développer.
Si la question est : Est-il plus rapide de développer une appli d'IHM en
C#/.NET framework qu'en C++/Bibliothèque qui va bien (wxWindows, QT...),
la réponse est bien plus difficile, et polémique. Un autre élément est
aussi de savoir si à terme on veut pouvoir tourner sur des plates-formes
non windows.
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant
qu'à faire autant demander..)
Probablement, mais je ne sais pas à quel point c'est fait proprement ou
au chausse pied.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec C++
?
Aucune idée.
Et la vitesse d'exécution ?
Ca doit dépendre du type d'application. Pour de l'IHM, on ne vera
peut-être pas de différence. Pour des applications intensives en calcul,
on risque de voir des différence non négligeables avec par exemple du
C++ utilisant des templates à bon escient.
5. Pouvez-vous me conseiller un bon bouquin en français pour développer des
applications Windows en C#? (je connais très très bien le C-UNIX, le C++, et
pas vraiment les API WIN32)
Non, désolé.
Merci de votre aide à tous :) J'hésite à apprendre le C++ avec l'api Win32
ou directement passer au C#... sachant que je veux développer des
applications Windows ;)
Je pense qu'utiliser directement l'API Win32 est une perte de temps
importante. Mais C# + .NET framework n'est pas la seule alternative.
Bon je vais peut-être me faire gronder en posant ces questions qui à mon avis ont déjà été posé, mais je les pose quand même car j'ai pas trouvé de réponses :(
Le critère de grondage est plus le hors sujet que la répétition de questions, même s'il ne faut pas exagérer.
1. Faut-il un moteur spécifique pour faire tourner des applications C# comme avec les applications Java ? Ou alors est-ce que les applications C# tournent sans aucun problème sous Win9X, Win2000, et XP ? Moteur spécifique. Qui a toutes les chances d'être inclus par défaut
dans les prochains windows.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ? Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Si la question est : Est-il plus rapide de développer une appli d'IHM en C#/.NET framework qu'en C++/Bibliothèque qui va bien (wxWindows, QT...), la réponse est bien plus difficile, et polémique. Un autre élément est aussi de savoir si à terme on veut pouvoir tourner sur des plates-formes non windows.
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant qu'à faire autant demander..) Probablement, mais je ne sais pas à quel point c'est fait proprement ou
au chausse pied.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec C++ ? Aucune idée.
Et la vitesse d'exécution ? Ca doit dépendre du type d'application. Pour de l'IHM, on ne vera
peut-être pas de différence. Pour des applications intensives en calcul, on risque de voir des différence non négligeables avec par exemple du C++ utilisant des templates à bon escient.
5. Pouvez-vous me conseiller un bon bouquin en français pour développer des applications Windows en C#? (je connais très très bien le C-UNIX, le C++, et pas vraiment les API WIN32) Non, désolé.
Merci de votre aide à tous :) J'hésite à apprendre le C++ avec l'api Win32 ou directement passer au C#... sachant que je veux développer des applications Windows ;)
Je pense qu'utiliser directement l'API Win32 est une perte de temps importante. Mais C# + .NET framework n'est pas la seule alternative.
-- Loïc
Michel Michaud
Dans news:bnpchl$9nr$, Loïc
TigrouMeow wrote:
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ? Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas) et qui permet des développements plus rapides que C# ou VB ! (on peut intégrer du non « managé » dans les programmes C++).
Sinon on devra dire simplement que VB ou C# sont des outils plus rapides que C++, « managé » ou pas. Je ne crois pas que ce soit le cas... (c'était le cas avant .NET 2003, quand il n'y avait pas l'outil visuel de développement des formes).
Comme toujours la vraie question est « quel type de programme doit- on développé ? ». Si le programme sera utilisé une fois ou deux puis jeté, alors C++ n'est pas le meilleur outil. Si le programme doit être prévu pour une longue durée de vie, il faut le développer plus sérieusement et c'est plus facile en C++.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer que le prochain C++/CLI sera beaucoup mieux que Managed C++...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bnpchl$9nr$1@news-reader4.wanadoo.fr, Loïc
TigrouMeow wrote:
2. Est-ce vraiment plus rapide que le C++ pour développer des
applications Windows ?
Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et
les efforts marketing (récupération de code sur site web...) et fait
pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose
d'utiliser le C++ d'un façon contre nature qui n'améliore ni la
qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas)
et qui permet des développements plus rapides que C# ou VB !
(on peut intégrer du non « managé » dans les programmes C++).
Sinon on devra dire simplement que VB ou C# sont des outils plus
rapides que C++, « managé » ou pas. Je ne crois pas que ce soit le
cas... (c'était le cas avant .NET 2003, quand il n'y avait pas
l'outil visuel de développement des formes).
Comme toujours la vraie question est « quel type de programme doit-
on développé ? ». Si le programme sera utilisé une fois ou deux
puis jeté, alors C++ n'est pas le meilleur outil. Si le programme
doit être prévu pour une longue durée de vie, il faut le développer
plus sérieusement et c'est plus facile en C++.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer
que le prochain C++/CLI sera beaucoup mieux que Managed C++...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ? Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas) et qui permet des développements plus rapides que C# ou VB ! (on peut intégrer du non « managé » dans les programmes C++).
Sinon on devra dire simplement que VB ou C# sont des outils plus rapides que C++, « managé » ou pas. Je ne crois pas que ce soit le cas... (c'était le cas avant .NET 2003, quand il n'y avait pas l'outil visuel de développement des formes).
Comme toujours la vraie question est « quel type de programme doit- on développé ? ». Si le programme sera utilisé une fois ou deux puis jeté, alors C++ n'est pas le meilleur outil. Si le programme doit être prévu pour une longue durée de vie, il faut le développer plus sérieusement et c'est plus facile en C++.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer que le prochain C++/CLI sera beaucoup mieux que Managed C++...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
_M.B._
"Philippe Guglielmetti" a écrit dans le message news: 3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif. --
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
MB
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message news:
3f9f9382$0$3666$5402220f@news.sunrise.ch...
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
--
Non.
Le bytecode est compilé lors de la premiere execution du programme
(compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
"Philippe Guglielmetti" a écrit dans le message news: 3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif. --
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
MB
Loïc Joly
Michel Michaud wrote:
Dans news:bnpchl$9nr$, Loïc
TigrouMeow wrote:
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Pour des applications utilisant le .NET framework, c'est très certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas) et qui permet des développements plus rapides que C# ou VB ! (on peut intégrer du non « managé » dans les programmes C++).
Tout comme on peut intégrer du C++ dans du C#. Je parlais en l'occurence de la partie IHM de l'application, pour laquelle, si on utilise le .NET framework, le C# ou le VB me semblent plus adaptés que le C++ managé.
Ma vision d'une vraie (c'est à dire avec un vrai comportement derrière, pas seulement un accès à des bases de données) appli telle que voulue par Microsoft, c'est l'IHM en C#, interfacée avec un coeur de programme en vrai C++, l'interface elle même étant une couche de C++ managé la plus étroite possible.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer que le prochain C++/CLI sera beaucoup mieux que Managed C++...
J'ai pas lu tous les détails, mais ce que j'en ai lu semble en effet aller dans le bon sens.
-- Loïc
Michel Michaud wrote:
Dans news:bnpchl$9nr$1@news-reader4.wanadoo.fr, Loïc
TigrouMeow wrote:
2. Est-ce vraiment plus rapide que le C++ pour développer des
applications Windows ?
Pour des applications utilisant le .NET framework, c'est très
certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et
les efforts marketing (récupération de code sur site web...) et fait
pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose
d'utiliser le C++ d'un façon contre nature qui n'améliore ni la
qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas)
et qui permet des développements plus rapides que C# ou VB !
(on peut intégrer du non « managé » dans les programmes C++).
Tout comme on peut intégrer du C++ dans du C#. Je parlais en l'occurence
de la partie IHM de l'application, pour laquelle, si on utilise le .NET
framework, le C# ou le VB me semblent plus adaptés que le C++ managé.
Ma vision d'une vraie (c'est à dire avec un vrai comportement derrière,
pas seulement un accès à des bases de données) appli telle que voulue
par Microsoft, c'est l'IHM en C#, interfacée avec un coeur de programme
en vrai C++, l'interface elle même étant une couche de C++ managé la
plus étroite possible.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer
que le prochain C++/CLI sera beaucoup mieux que Managed C++...
J'ai pas lu tous les détails, mais ce que j'en ai lu semble en effet
aller dans le bon sens.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Pour des applications utilisant le .NET framework, c'est très certaineemnt plus rapide que le C++ managé. Déjà, toute la doc et les efforts marketing (récupération de code sur site web...) et fait pour C# ou VB, pas pour C++ managé, ensuite, le C++ managé impose d'utiliser le C++ d'un façon contre nature qui n'améliore ni la qualité ni le temps passé à développer.
Mais tu oublies tout ce qu'on peut faire en C++ (« managé » ou pas) et qui permet des développements plus rapides que C# ou VB ! (on peut intégrer du non « managé » dans les programmes C++).
Tout comme on peut intégrer du C++ dans du C#. Je parlais en l'occurence de la partie IHM de l'application, pour laquelle, si on utilise le .NET framework, le C# ou le VB me semblent plus adaptés que le C++ managé.
Ma vision d'une vraie (c'est à dire avec un vrai comportement derrière, pas seulement un accès à des bases de données) appli telle que voulue par Microsoft, c'est l'IHM en C#, interfacée avec un coeur de programme en vrai C++, l'interface elle même étant une couche de C++ managé la plus étroite possible.
Ceci dit, ce que Herb Sutter a annoncé sur clc++m semble indiquer que le prochain C++/CLI sera beaucoup mieux que Managed C++...
J'ai pas lu tous les détails, mais ce que j'en ai lu semble en effet aller dans le bon sens.
-- Loïc
Michel Michaud
Dans news:bnqd2b$p5a$, Loïc
Tout comme on peut intégrer du C++ dans du C#. Je parlais en l'occurence de la partie IHM de l'application, pour laquelle, si on utilise le .NET framework, le C# ou le VB me semblent plus adaptés que le C++ managé.
Mais si on fait la majeure partie de l'IHM avec l'outil visuel, on ne voit vraiment pas de différence majeure. Il doit y avoir un point de vue que je ne comprends pas...
Ma vision d'une vraie (c'est à dire avec un vrai comportement derrière, pas seulement un accès à des bases de données) appli telle que voulue par Microsoft, c'est l'IHM en C#, interfacée avec un coeur de programme en vrai C++, l'interface elle même étant une couche de C++ managé la plus étroite possible.
Moi je vois plutôt : IHM développé avec les outils visuels, le reste en ce qu'on voudra (et C++ me paraît aussi bien, sinon mieux, que VB, C# ou autre J#...). Mais bon, je dois avouer que je n'ai pas bien compris l'intérêt de C# quand on connaît déjà C++...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bnqd2b$p5a$1@news-reader2.wanadoo.fr, Loïc
Tout comme on peut intégrer du C++ dans du C#. Je parlais en
l'occurence de la partie IHM de l'application, pour laquelle, si on
utilise le .NET framework, le C# ou le VB me semblent plus adaptés
que le C++ managé.
Mais si on fait la majeure partie de l'IHM avec l'outil visuel, on
ne voit vraiment pas de différence majeure. Il doit y avoir un
point de vue que je ne comprends pas...
Ma vision d'une vraie (c'est à dire avec un vrai comportement
derrière, pas seulement un accès à des bases de données) appli
telle que voulue par Microsoft, c'est l'IHM en C#, interfacée avec
un coeur de programme en vrai C++, l'interface elle même étant une
couche de C++ managé la plus étroite possible.
Moi je vois plutôt : IHM développé avec les outils visuels, le
reste en ce qu'on voudra (et C++ me paraît aussi bien, sinon mieux,
que VB, C# ou autre J#...). Mais bon, je dois avouer que je n'ai
pas bien compris l'intérêt de C# quand on connaît déjà C++...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Tout comme on peut intégrer du C++ dans du C#. Je parlais en l'occurence de la partie IHM de l'application, pour laquelle, si on utilise le .NET framework, le C# ou le VB me semblent plus adaptés que le C++ managé.
Mais si on fait la majeure partie de l'IHM avec l'outil visuel, on ne voit vraiment pas de différence majeure. Il doit y avoir un point de vue que je ne comprends pas...
Ma vision d'une vraie (c'est à dire avec un vrai comportement derrière, pas seulement un accès à des bases de données) appli telle que voulue par Microsoft, c'est l'IHM en C#, interfacée avec un coeur de programme en vrai C++, l'interface elle même étant une couche de C++ managé la plus étroite possible.
Moi je vois plutôt : IHM développé avec les outils visuels, le reste en ce qu'on voudra (et C++ me paraît aussi bien, sinon mieux, que VB, C# ou autre J#...). Mais bon, je dois avouer que je n'ai pas bien compris l'intérêt de C# quand on connaît déjà C++...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Loïc Joly
_M.B._ wrote:
"Philippe Guglielmetti" a écrit dans le message news: 3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif. --
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire on compile une fonction uniquement quand on risque d'en avoir besoin. J'ai l'impression que si on compilait uniquement lors de la première exécution du programme, déjà il faudrait un temps non négligeable pour lancer ce programme, mais en plus il faudrait pouvoir stocker le résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque fois, ce qui poserait problème sur des configurations pour lesquelles on n'a pas de droits d'écriture. Et finalement, pour que le JIT puisse être plus rapide, une technique est d'utiliser les résultats des premiers appels d'une fonction pour la recompiler différement de manière plus efficace en tenant compte de données d'entrées d'icelle.
-- Loïc
_M.B._ wrote:
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message news:
3f9f9382$0$3666$5402220f@news.sunrise.ch...
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
--
Non.
Le bytecode est compilé lors de la premiere execution du programme
(compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire
on compile une fonction uniquement quand on risque d'en avoir besoin.
J'ai l'impression que si on compilait uniquement lors de la première
exécution du programme, déjà il faudrait un temps non négligeable pour
lancer ce programme, mais en plus il faudrait pouvoir stocker le
résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque
fois, ce qui poserait problème sur des configurations pour lesquelles on
n'a pas de droits d'écriture.
Et finalement, pour que le JIT puisse être plus rapide, une technique
est d'utiliser les résultats des premiers appels d'une fonction pour la
recompiler différement de manière plus efficace en tenant compte de
données d'entrées d'icelle.
"Philippe Guglielmetti" a écrit dans le message news: 3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif. --
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire on compile une fonction uniquement quand on risque d'en avoir besoin. J'ai l'impression que si on compilait uniquement lors de la première exécution du programme, déjà il faudrait un temps non négligeable pour lancer ce programme, mais en plus il faudrait pouvoir stocker le résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque fois, ce qui poserait problème sur des configurations pour lesquelles on n'a pas de droits d'écriture. Et finalement, pour que le JIT puisse être plus rapide, une technique est d'utiliser les résultats des premiers appels d'une fonction pour la recompiler différement de manière plus efficace en tenant compte de données d'entrées d'icelle.
-- Loïc
_M.B._
"Loïc Joly" a écrit dans le message news: bns0bt$osk$
_M.B._ wrote:
"Philippe Guglielmetti" a écrit dans le message news:
3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
--
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire on compile une fonction uniquement quand on risque d'en avoir besoin. J'ai l'impression que si on compilait uniquement lors de la première exécution du programme, déjà il faudrait un temps non négligeable pour lancer ce programme, mais en plus il faudrait pouvoir stocker le résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque fois, ce qui poserait problème sur des configurations pour lesquelles on n'a pas de droits d'écriture. Et finalement, pour que le JIT puisse être plus rapide, une technique est d'utiliser les résultats des premiers appels d'une fonction pour la recompiler différement de manière plus efficace en tenant compte de données d'entrées d'icelle.
Ben oui, mais c'est comme ca, c'est pas moi qui l'ai inventé. Le resultat se réécrit sur l'exe en byte-code. Il est donc beaucoup plus rapide aux executions autres que la premiere. On peut lever ce probleme sur la premiere execution en lancant la compilation a l'install.
MB
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
bns0bt$osk$1@news-reader1.wanadoo.fr...
_M.B._ wrote:
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message
news:
3f9f9382$0$3666$5402220f@news.sunrise.ch...
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du
natif.
--
Non.
Le bytecode est compilé lors de la premiere execution du programme
(compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire
on compile une fonction uniquement quand on risque d'en avoir besoin.
J'ai l'impression que si on compilait uniquement lors de la première
exécution du programme, déjà il faudrait un temps non négligeable pour
lancer ce programme, mais en plus il faudrait pouvoir stocker le
résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque
fois, ce qui poserait problème sur des configurations pour lesquelles on
n'a pas de droits d'écriture.
Et finalement, pour que le JIT puisse être plus rapide, une technique
est d'utiliser les résultats des premiers appels d'une fonction pour la
recompiler différement de manière plus efficace en tenant compte de
données d'entrées d'icelle.
Ben oui, mais c'est comme ca, c'est pas moi qui l'ai inventé.
Le resultat se réécrit sur l'exe en byte-code.
Il est donc beaucoup plus rapide aux executions autres que la
premiere. On peut lever ce probleme sur la premiere execution
en lancant la compilation a l'install.
"Loïc Joly" a écrit dans le message news: bns0bt$osk$
_M.B._ wrote:
"Philippe Guglielmetti" a écrit dans le message news:
3f9f9382$0$3666$
? Et la vitesse d'exécution ?
les langages .NET génèrent un bytecode, forcément plus lent que du natif.
--
Non.
Le bytecode est compilé lors de la premiere execution du programme (compilation JIT : Just In Time), ou lors de l'install.
Apres c'est un exe normal, meme vitesse d'execution.
Ce n'est pas l'impression que j'avais. Pour moi, JIT ça veut putôt dire on compile une fonction uniquement quand on risque d'en avoir besoin. J'ai l'impression que si on compilait uniquement lors de la première exécution du programme, déjà il faudrait un temps non négligeable pour lancer ce programme, mais en plus il faudrait pouvoir stocker le résultat quelque part pour pouvoir ne pas avoir à recompiler à chaque fois, ce qui poserait problème sur des configurations pour lesquelles on n'a pas de droits d'écriture. Et finalement, pour que le JIT puisse être plus rapide, une technique est d'utiliser les résultats des premiers appels d'une fonction pour la recompiler différement de manière plus efficace en tenant compte de données d'entrées d'icelle.
Ben oui, mais c'est comme ca, c'est pas moi qui l'ai inventé. Le resultat se réécrit sur l'exe en byte-code. Il est donc beaucoup plus rapide aux executions autres que la premiere. On peut lever ce probleme sur la premiere execution en lancant la compilation a l'install.
