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 ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry
Bonjour,
TigrouMeow a écrit :
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 ?
Il faut le framework .Net d'installé sur la machine cible.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Si tu ne connais pas le C++/API windows, je dirais oui.
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Bonjour,
TigrouMeow a écrit :
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 ?
Il faut le framework .Net d'installé sur la machine cible.
2. Est-ce vraiment plus rapide que le C++ pour développer des
applications Windows ?
Si tu ne connais pas le C++/API windows, je dirais oui.
--
"MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
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 ?
Il faut le framework .Net d'installé sur la machine cible.
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
Si tu ne connais pas le C++/API windows, je dirais oui.
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Ambassadeur Kosh
> 1. Faut-il un moteur spécifique pour faire tourner des applications C#
comme
avec les applications Java ?
c'est le même principe.
Ou alors est-ce que les applications C# tournent sans aucun problème sous Win9X, Win2000, et XP ?
ça ne s'oppose pas forcement avec la premiere partie de la conjonction :)
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
moi je dirais oui.
mais il y aura toujours des gens pour te dire que pisser 150 lignes de SDK et de MFC pour affecter un icone à un Panel c'est mieux, c'est tres facile, et ça a plein d'avantages par rapport à écrire Panel1.Icon = icon , comme par exemple gagner un millionieme de seconde à la premiere ouverture de la fenêtre :)
C++ Builder a un Framework "équivalent" à C# et apporte le même potentiel d'orientation composant, de conception visuelle et tout ça... Visual C++ n'apporte rien du tout et suppose que tu pisses tout le code à la main ou presque, (à part le void main dont il te fait grace et la dizaine de macros auquelles on pige rien et sans qui ça ne marche pas). donc ça n'est pas des langages qu'il faut comparer, mais des produits.
maintenant je te donne un exemple concret qui date d'une semaine. un docteur en informatique qui travaille à la fac à Dijon. il bosse avec Visual C++ 6. son appli calcule pendant 10 minutes une image et la trace pixel par pixel à l'écran au fur et à mesure. évidement, si on passe une fenetre par dessus, l'image disparait. je lui pose donc la question : - pas de WM_PAINT ? - ben non, sinon ça va recalculer pendant 10 minutes à chaque fois. c'est insupportable. - pourquoi ne pas stocker l'image dans un Bitmap et peindre ce Bitmap dans WM_PAINT ? le fait que ça soit des messages est une section critique qui garantit l'exclusion mutuelle. non ? - j'ai essayé, mais ça me fait des erreurs en debug, mais par contre pas à l'execution. et en plus, le bitmap ne se met pas à la taille de la fenêtre. - oui, mais ça, c'est juste un pauvre parametre dans la fonction de tracage. un STRETCH ou qq chose du genre. - tiens, j'ai collé ce bout de code qui vient du MSDN, mais ça marche pas, puis en plus ça va prendre trop de temps à redessiner.
sur un P4, avec une GForce qui calcule des rendus de milliers de facettes en quelques cycles, faire un stretch d'un bitmap 320x200, pour le mettre à la taille de la fenêtre, ça prend trop de temps. à un tel point qu'il faut preferer dessiner pixel par pixel le resultat. ce type avait tellement honte qu'il s'est senti obligé de mentir. alors qu'en fait il n'y a pas de honte à avoir. dans son bout de code, il y avait 5 lignes au dessus et 5 lignes en dessous du BitBlt auquelles on ne pigeait pas forcément tout sans y consacrer une heure. sans compter la recherche des bugs. des ReleaseDC, des SelectObject, et j'en passe... pas d'objets typés, bien sur, que des handle (des entiers). de l'assembleur quoi. avec les MFC ou avec le SDK, c'est du pareil au même. ça marche jamais et tu cherches pourquoi pendant 30 plombes.
en C#, tu poses une PictureBox sur ta fenêtre, tu mets le SizeMode à StretchImage dans les propriétés, et tu Dock l'image sur toute la fenêtre. et pour affecter l'image, tu écris pictureBox1.Image = monResultatDuCalcul ;
et ça a pris 30 secondes avec un verre de coca light dans l'autre main, ça fonctionne du premier coup et c'est correct et complet.
mais bon, ça doit être moi qui fait du cretinisme. j'arrete la, ça m'enerve tiens :)
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant qu'à faire autant demander..)
oui. et ça bouffe du COM et de la dll à volonté.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec
C++
? Et la vitesse d'exécution ?
1) qu'est ce que ça peut bien foutre. t'es pas à deux kilos pres, et de toute façon, dans l'avenir, le Framework sera integré aux systeme(s). 2) tu serais surpris des performances. ceci dit, comme c'est du PCode, c'est forcément un peu plus lent pour certaines choses.
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)
fait toi déja 15 jours d'essais.
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 ;)
y'a pas photo, mais bon...
si tu as des besoins enormes en perfs, tu peux toujours écrire des classes en C++, les compiler et les utiliser en C#. un jour ou l'autre, il faudra bouffer du Win32. le framework contient des classes, mais pas toutes celles qu'on aurait pu imaginer. mais bon, voila, pour les choses simples, pas besoin de galérer pendant 40 jours sans boire et sans manger dans le msdesert.
<troll enabled="yes"/>
> 1. Faut-il un moteur spécifique pour faire tourner des applications C#
comme
avec les applications Java ?
c'est le même principe.
Ou alors est-ce que les applications C#
tournent sans aucun problème sous Win9X, Win2000, et XP ?
ça ne s'oppose pas forcement avec la premiere partie de la conjonction :)
2. Est-ce vraiment plus rapide que le C++ pour développer des applications
Windows ?
moi je dirais oui.
mais il y aura toujours des gens pour te dire que pisser 150 lignes de SDK
et de MFC pour affecter un icone à un Panel c'est mieux, c'est tres facile,
et ça a plein d'avantages par rapport à écrire Panel1.Icon = icon , comme
par exemple gagner un millionieme de seconde à la premiere ouverture de la
fenêtre :)
C++ Builder a un Framework "équivalent" à C# et apporte le même potentiel
d'orientation composant, de conception visuelle et tout ça... Visual C++
n'apporte rien du tout et suppose que tu pisses tout le code à la main ou
presque, (à part le void main dont il te fait grace et la dizaine de macros
auquelles on pige rien et sans qui ça ne marche pas). donc ça n'est pas des
langages qu'il faut comparer, mais des produits.
maintenant je te donne un exemple concret qui date d'une semaine. un docteur
en informatique qui travaille à la fac à Dijon. il bosse avec Visual C++ 6.
son appli calcule pendant 10 minutes une image et la trace pixel par pixel à
l'écran au fur et à mesure. évidement, si on passe une fenetre par dessus,
l'image disparait. je lui pose donc la question :
- pas de WM_PAINT ?
- ben non, sinon ça va recalculer pendant 10 minutes à chaque fois. c'est
insupportable.
- pourquoi ne pas stocker l'image dans un Bitmap et peindre ce Bitmap dans
WM_PAINT ? le fait que ça soit des messages est une section critique qui
garantit l'exclusion mutuelle. non ?
- j'ai essayé, mais ça me fait des erreurs en debug, mais par contre pas à
l'execution. et en plus, le bitmap ne se met pas à la taille de la fenêtre.
- oui, mais ça, c'est juste un pauvre parametre dans la fonction de tracage.
un STRETCH ou qq chose du genre.
- tiens, j'ai collé ce bout de code qui vient du MSDN, mais ça marche pas,
puis en plus ça va prendre trop de temps à redessiner.
sur un P4, avec une GForce qui calcule des rendus de milliers de facettes en
quelques cycles, faire un stretch d'un bitmap 320x200, pour le mettre à la
taille de la fenêtre, ça prend trop de temps. à un tel point qu'il faut
preferer dessiner pixel par pixel le resultat. ce type avait tellement honte
qu'il s'est senti obligé de mentir. alors qu'en fait il n'y a pas de honte à
avoir. dans son bout de code, il y avait 5 lignes au dessus et 5 lignes en
dessous du BitBlt auquelles on ne pigeait pas forcément tout sans y
consacrer une heure. sans compter la recherche des bugs. des ReleaseDC, des
SelectObject, et j'en passe... pas d'objets typés, bien sur, que des handle
(des entiers). de l'assembleur quoi. avec les MFC ou avec le SDK, c'est du
pareil au même. ça marche jamais et tu cherches pourquoi pendant 30 plombes.
en C#, tu poses une PictureBox sur ta fenêtre, tu mets le SizeMode à
StretchImage dans les propriétés, et tu Dock l'image sur toute la fenêtre.
et pour affecter l'image, tu écris pictureBox1.Image = monResultatDuCalcul ;
et ça a pris 30 secondes avec un verre de coca light dans l'autre main, ça
fonctionne du premier coup et c'est correct et complet.
mais bon, ça doit être moi qui fait du cretinisme. j'arrete la, ça m'enerve
tiens :)
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant
qu'à faire autant demander..)
oui.
et ça bouffe du COM et de la dll à volonté.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec
C++
? Et la vitesse d'exécution ?
1) qu'est ce que ça peut bien foutre. t'es pas à deux kilos pres, et de
toute façon, dans l'avenir, le Framework sera integré aux systeme(s).
2) tu serais surpris des performances. ceci dit, comme c'est du PCode, c'est
forcément un peu plus lent pour certaines choses.
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)
fait toi déja 15 jours d'essais.
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 ;)
y'a pas photo, mais bon...
si tu as des besoins enormes en perfs, tu peux toujours écrire des classes
en C++, les compiler et les utiliser en C#.
un jour ou l'autre, il faudra bouffer du Win32. le framework contient des
classes, mais pas toutes celles qu'on aurait pu imaginer.
mais bon, voila, pour les choses simples, pas besoin de galérer pendant 40
jours sans boire et sans manger dans le msdesert.
> 1. Faut-il un moteur spécifique pour faire tourner des applications C#
comme
avec les applications Java ?
c'est le même principe.
Ou alors est-ce que les applications C# tournent sans aucun problème sous Win9X, Win2000, et XP ?
ça ne s'oppose pas forcement avec la premiere partie de la conjonction :)
2. Est-ce vraiment plus rapide que le C++ pour développer des applications Windows ?
moi je dirais oui.
mais il y aura toujours des gens pour te dire que pisser 150 lignes de SDK et de MFC pour affecter un icone à un Panel c'est mieux, c'est tres facile, et ça a plein d'avantages par rapport à écrire Panel1.Icon = icon , comme par exemple gagner un millionieme de seconde à la premiere ouverture de la fenêtre :)
C++ Builder a un Framework "équivalent" à C# et apporte le même potentiel d'orientation composant, de conception visuelle et tout ça... Visual C++ n'apporte rien du tout et suppose que tu pisses tout le code à la main ou presque, (à part le void main dont il te fait grace et la dizaine de macros auquelles on pige rien et sans qui ça ne marche pas). donc ça n'est pas des langages qu'il faut comparer, mais des produits.
maintenant je te donne un exemple concret qui date d'une semaine. un docteur en informatique qui travaille à la fac à Dijon. il bosse avec Visual C++ 6. son appli calcule pendant 10 minutes une image et la trace pixel par pixel à l'écran au fur et à mesure. évidement, si on passe une fenetre par dessus, l'image disparait. je lui pose donc la question : - pas de WM_PAINT ? - ben non, sinon ça va recalculer pendant 10 minutes à chaque fois. c'est insupportable. - pourquoi ne pas stocker l'image dans un Bitmap et peindre ce Bitmap dans WM_PAINT ? le fait que ça soit des messages est une section critique qui garantit l'exclusion mutuelle. non ? - j'ai essayé, mais ça me fait des erreurs en debug, mais par contre pas à l'execution. et en plus, le bitmap ne se met pas à la taille de la fenêtre. - oui, mais ça, c'est juste un pauvre parametre dans la fonction de tracage. un STRETCH ou qq chose du genre. - tiens, j'ai collé ce bout de code qui vient du MSDN, mais ça marche pas, puis en plus ça va prendre trop de temps à redessiner.
sur un P4, avec une GForce qui calcule des rendus de milliers de facettes en quelques cycles, faire un stretch d'un bitmap 320x200, pour le mettre à la taille de la fenêtre, ça prend trop de temps. à un tel point qu'il faut preferer dessiner pixel par pixel le resultat. ce type avait tellement honte qu'il s'est senti obligé de mentir. alors qu'en fait il n'y a pas de honte à avoir. dans son bout de code, il y avait 5 lignes au dessus et 5 lignes en dessous du BitBlt auquelles on ne pigeait pas forcément tout sans y consacrer une heure. sans compter la recherche des bugs. des ReleaseDC, des SelectObject, et j'en passe... pas d'objets typés, bien sur, que des handle (des entiers). de l'assembleur quoi. avec les MFC ou avec le SDK, c'est du pareil au même. ça marche jamais et tu cherches pourquoi pendant 30 plombes.
en C#, tu poses une PictureBox sur ta fenêtre, tu mets le SizeMode à StretchImage dans les propriétés, et tu Dock l'image sur toute la fenêtre. et pour affecter l'image, tu écris pictureBox1.Image = monResultatDuCalcul ;
et ça a pris 30 secondes avec un verre de coca light dans l'autre main, ça fonctionne du premier coup et c'est correct et complet.
mais bon, ça doit être moi qui fait du cretinisme. j'arrete la, ça m'enerve tiens :)
3. Est-ce que cela gère DirectX et OpenGL ? (je suppose que oui mais tant qu'à faire autant demander..)
oui. et ça bouffe du COM et de la dll à volonté.
4. Quand à la taille de l'application finale ? Est-ce plus gros qu'avec
C++
? Et la vitesse d'exécution ?
1) qu'est ce que ça peut bien foutre. t'es pas à deux kilos pres, et de toute façon, dans l'avenir, le Framework sera integré aux systeme(s). 2) tu serais surpris des performances. ceci dit, comme c'est du PCode, c'est forcément un peu plus lent pour certaines choses.
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)
fait toi déja 15 jours d'essais.
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 ;)
y'a pas photo, mais bon...
si tu as des besoins enormes en perfs, tu peux toujours écrire des classes en C++, les compiler et les utiliser en C#. un jour ou l'autre, il faudra bouffer du Win32. le framework contient des classes, mais pas toutes celles qu'on aurait pu imaginer. mais bon, voila, pour les choses simples, pas besoin de galérer pendant 40 jours sans boire et sans manger dans le msdesert.
<troll enabled="yes"/>
lgloub
Excellent ce post :)
Je tempérerai juste un peu en disant que se taper l'API windows et la gestion de message n'est pas qu'une prise de tête gratuite, mais permet de comprendre le fonctionnement réel des choses, ce qui n'est pas franchement du temps perdu pour un coder. En ce moment je galère avec du C / API parce que je connais pas bien, mais j'avoue que je prends plus de plaisir à faire ça que développer avec des surcouches, chose que je fais au quotidien dans mon boulot. Disons que j'ai un peu plus l'impression de me frotter au fond des choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun doute pour C# ou Java ;).
Excellent ce post :)
Je tempérerai juste un peu en disant que se taper l'API windows et la
gestion de message n'est pas qu'une prise de tête gratuite, mais permet
de comprendre le fonctionnement réel des choses, ce qui n'est pas
franchement du temps perdu pour un coder.
En ce moment je galère avec du C / API parce que je connais pas bien,
mais j'avoue que je prends plus de plaisir à faire ça que développer
avec des surcouches, chose que je fais au quotidien dans mon boulot.
Disons que j'ai un peu plus l'impression de me frotter au fond des choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun
doute pour C# ou Java ;).
Je tempérerai juste un peu en disant que se taper l'API windows et la gestion de message n'est pas qu'une prise de tête gratuite, mais permet de comprendre le fonctionnement réel des choses, ce qui n'est pas franchement du temps perdu pour un coder. En ce moment je galère avec du C / API parce que je connais pas bien, mais j'avoue que je prends plus de plaisir à faire ça que développer avec des surcouches, chose que je fais au quotidien dans mon boulot. Disons que j'ai un peu plus l'impression de me frotter au fond des choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun doute pour C# ou Java ;).
TigrouMeow
> Excellent ce post :)
Je tempérerai juste un peu en disant que se taper l'API windows et la gestion de message n'est pas qu'une prise de tête gratuite, mais permet de comprendre le fonctionnement réel des choses, ce qui n'est pas franchement du temps perdu pour un coder. En ce moment je galère avec du C / API parce que je connais pas bien, mais j'avoue que je prends plus de plaisir à faire ça que développer avec des surcouches, chose que je fais au quotidien dans mon boulot. Disons que j'ai un peu plus l'impression de me frotter au fond des
choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le lire ;) Et ta températion me parait exacte. Oui il faut que j'apprenne les deux. Je suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32 pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je vais m'y mettre et développer dès maintenant. Mes connaissances de l'API viendront par la suite :)
> Excellent ce post :)
Je tempérerai juste un peu en disant que se taper l'API windows et la
gestion de message n'est pas qu'une prise de tête gratuite, mais permet
de comprendre le fonctionnement réel des choses, ce qui n'est pas
franchement du temps perdu pour un coder.
En ce moment je galère avec du C / API parce que je connais pas bien,
mais j'avoue que je prends plus de plaisir à faire ça que développer
avec des surcouches, chose que je fais au quotidien dans mon boulot.
Disons que j'ai un peu plus l'impression de me frotter au fond des
choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun
doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le lire
;)
Et ta températion me parait exacte. Oui il faut que j'apprenne les deux. Je
suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32
pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je vais
m'y mettre et développer dès maintenant. Mes connaissances de l'API
viendront par la suite :)
Je tempérerai juste un peu en disant que se taper l'API windows et la gestion de message n'est pas qu'une prise de tête gratuite, mais permet de comprendre le fonctionnement réel des choses, ce qui n'est pas franchement du temps perdu pour un coder. En ce moment je galère avec du C / API parce que je connais pas bien, mais j'avoue que je prends plus de plaisir à faire ça que développer avec des surcouches, chose que je fais au quotidien dans mon boulot. Disons que j'ai un peu plus l'impression de me frotter au fond des
choses...
Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le lire ;) Et ta températion me parait exacte. Oui il faut que j'apprenne les deux. Je suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32 pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je vais m'y mettre et développer dès maintenant. Mes connaissances de l'API viendront par la suite :)
Cyrille \cns\ Szymanski
>> Excellent ce post :)
J'ajouterai que .NET, tout comme Java, me semble l'outil idéal pour développer un serveur.
Côté serveur, la compilation JIT ne pose aucun problème étant donné que le processus va exister pendant un temps suffisament long devant le temps de compilation. Avec un cache suffisament grand les routines fréquemment appelées ne seront compilées qu'une fois, garantissant un temps de réponse très bon. De même le temps de chargement du CLR est négligeable.
Ensuite le modèle "sandbox" et l'encapsulation des objets permet d'obtenir un niveau de sécurité correct. Par exemple les attaques de type buffer overrun sont limitées grâce aux nombreux contrôles d'accès mémoire.
Enfin il ne faut pas oublier le Garbage Collector. S'il est d'un intérêt relativement faible pour des processus qui ont une courte durée de vie, pouvoir se dispenser de la gestion des allocations/déallocations mémoire pour un projet de type serveur (ce qui ne veut pas dire "programmer comme un cochon") est un gors atout.
Les classes .NET font gagner beaucoup de temps par rapport au SDK. Evidemment cette affirmation est à nuancer en fonction de sa connaissance du SDK et de la possibilité de copier/coller du code. Un bon point de .NET est le support des io completion ports au moyen de la classe ThreadPool ce qui à mon avis est imbattable pour le rapport performance/complexité de code.
Quand je dis "serveur", je parle des applications serveur type serveur HTTP, mais aussi des scripts serveurs type CGI (ASP...).
Merci de confirmer/infirmer mes dires -- _|_|_| CnS _|_| for(n=0;b;n++) _| b&=b-1; /*pp.47 K&R*/
>> Excellent ce post :)
J'ajouterai que .NET, tout comme Java, me semble l'outil idéal pour
développer un serveur.
Côté serveur, la compilation JIT ne pose aucun problème étant donné que
le processus va exister pendant un temps suffisament long devant le temps
de compilation. Avec un cache suffisament grand les routines fréquemment
appelées ne seront compilées qu'une fois, garantissant un temps de
réponse très bon. De même le temps de chargement du CLR est négligeable.
Ensuite le modèle "sandbox" et l'encapsulation des objets permet
d'obtenir un niveau de sécurité correct. Par exemple les attaques de type
buffer overrun sont limitées grâce aux nombreux contrôles d'accès
mémoire.
Enfin il ne faut pas oublier le Garbage Collector. S'il est d'un intérêt
relativement faible pour des processus qui ont une courte durée de vie,
pouvoir se dispenser de la gestion des allocations/déallocations mémoire
pour un projet de type serveur (ce qui ne veut pas dire "programmer comme
un cochon") est un gors atout.
Les classes .NET font gagner beaucoup de temps par rapport au SDK.
Evidemment cette affirmation est à nuancer en fonction de sa connaissance
du SDK et de la possibilité de copier/coller du code. Un bon point de
.NET est le support des io completion ports au moyen de la classe
ThreadPool ce qui à mon avis est imbattable pour le rapport
performance/complexité de code.
Quand je dis "serveur", je parle des applications serveur type serveur
HTTP, mais aussi des scripts serveurs type CGI (ASP...).
Merci de confirmer/infirmer mes dires
--
_|_|_| CnS
_|_| for(n=0;b;n++)
_| b&=b-1; /*pp.47 K&R*/
J'ajouterai que .NET, tout comme Java, me semble l'outil idéal pour développer un serveur.
Côté serveur, la compilation JIT ne pose aucun problème étant donné que le processus va exister pendant un temps suffisament long devant le temps de compilation. Avec un cache suffisament grand les routines fréquemment appelées ne seront compilées qu'une fois, garantissant un temps de réponse très bon. De même le temps de chargement du CLR est négligeable.
Ensuite le modèle "sandbox" et l'encapsulation des objets permet d'obtenir un niveau de sécurité correct. Par exemple les attaques de type buffer overrun sont limitées grâce aux nombreux contrôles d'accès mémoire.
Enfin il ne faut pas oublier le Garbage Collector. S'il est d'un intérêt relativement faible pour des processus qui ont une courte durée de vie, pouvoir se dispenser de la gestion des allocations/déallocations mémoire pour un projet de type serveur (ce qui ne veut pas dire "programmer comme un cochon") est un gors atout.
Les classes .NET font gagner beaucoup de temps par rapport au SDK. Evidemment cette affirmation est à nuancer en fonction de sa connaissance du SDK et de la possibilité de copier/coller du code. Un bon point de .NET est le support des io completion ports au moyen de la classe ThreadPool ce qui à mon avis est imbattable pour le rapport performance/complexité de code.
Quand je dis "serveur", je parle des applications serveur type serveur HTTP, mais aussi des scripts serveurs type CGI (ASP...).
Merci de confirmer/infirmer mes dires -- _|_|_| CnS _|_| for(n=0;b;n++) _| b&=b-1; /*pp.47 K&R*/
Reste à savoir si on peut vendre et distribuer une application .net au grand public sans prendre plus de précautions qu'avec une compilation classique.
Reste à savoir si on peut vendre et distribuer une application .net au
grand public sans prendre plus de précautions qu'avec une compilation
classique.
Reste à savoir si on peut vendre et distribuer une application .net au grand public sans prendre plus de précautions qu'avec une compilation classique.
"TigrouMeow" a écrit dans le message de news:3fa0c8dc$0$2799$
> Excellent ce post :) > > Je tempérerai juste un peu en disant que se taper l'API windows et la > gestion de message n'est pas qu'une prise de tête gratuite, mais permet > de comprendre le fonctionnement réel des choses, ce qui n'est pas > franchement du temps perdu pour un coder. > En ce moment je galère avec du C / API parce que je connais pas bien, > mais j'avoue que je prends plus de plaisir à faire ça que développer > avec des surcouches, chose que je fais au quotidien dans mon boulot. > Disons que j'ai un peu plus l'impression de me frotter au fond des choses... > > Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun > doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le
lire
;) Et ta températion me parait exacte. Oui il faut que j'apprenne les deux.
Je
suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32 pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je
vais
m'y mettre et développer dès maintenant. Mes connaissances de l'API viendront par la suite :)
Je peux te dire que si utilises C++ Builder (par exemple) tu passeras à C# sans difficulté. L'inverse n'est pas complétement vrai je pense. Moi à ta place j'apprendrai les deux. De toutes façons les concepts sont pas bien loin.
"TigrouMeow" <TigrouMeow-NOSPAM-@-NOSPAM-OnLine.Fr> a écrit dans le message
de news:3fa0c8dc$0$2799$626a54ce@news.free.fr...
> Excellent ce post :)
>
> Je tempérerai juste un peu en disant que se taper l'API windows et la
> gestion de message n'est pas qu'une prise de tête gratuite, mais permet
> de comprendre le fonctionnement réel des choses, ce qui n'est pas
> franchement du temps perdu pour un coder.
> En ce moment je galère avec du C / API parce que je connais pas bien,
> mais j'avoue que je prends plus de plaisir à faire ça que développer
> avec des surcouches, chose que je fais au quotidien dans mon boulot.
> Disons que j'ai un peu plus l'impression de me frotter au fond des
choses...
>
> Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun
> doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le
lire
;)
Et ta températion me parait exacte. Oui il faut que j'apprenne les deux.
Je
suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32
pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je
vais
m'y mettre et développer dès maintenant. Mes connaissances de l'API
viendront par la suite :)
Je peux te dire que si utilises C++ Builder (par exemple) tu passeras à C#
sans difficulté.
L'inverse n'est pas complétement vrai je pense.
Moi à ta place j'apprendrai les deux.
De toutes façons les concepts sont pas bien loin.
"TigrouMeow" a écrit dans le message de news:3fa0c8dc$0$2799$
> Excellent ce post :) > > Je tempérerai juste un peu en disant que se taper l'API windows et la > gestion de message n'est pas qu'une prise de tête gratuite, mais permet > de comprendre le fonctionnement réel des choses, ce qui n'est pas > franchement du temps perdu pour un coder. > En ce moment je galère avec du C / API parce que je connais pas bien, > mais j'avoue que je prends plus de plaisir à faire ça que développer > avec des surcouches, chose que je fais au quotidien dans mon boulot. > Disons que j'ai un peu plus l'impression de me frotter au fond des choses... > > Ceci dit, si je devais faire une grosse appli, j'opterai sans aucun > doute pour C# ou Java ;).
J'ai aussi trouvé le post de Kosh excellent, j'ai pris du plaisir à le
lire
;) Et ta températion me parait exacte. Oui il faut que j'apprenne les deux.
Je
suis encore étudiant, et de toute façon on va bouffer du C++/APIWIN32 pendant un an à fond... et le C# je suis pas sur de l'étudier, donc je
vais
m'y mettre et développer dès maintenant. Mes connaissances de l'API viendront par la suite :)
Je peux te dire que si utilises C++ Builder (par exemple) tu passeras à C# sans difficulté. L'inverse n'est pas complétement vrai je pense. Moi à ta place j'apprendrai les deux. De toutes façons les concepts sont pas bien loin.
