L'interêt du C# sur le C++ :

- le Garbage Collector
- La réflexion
- On ne manipule pas de pointeurs

Le désavantage :

- On perd parfois en performances (C#/WPF par rapport a C++/QT par exemple)
- On prend parfois de mauvaises habitudes (Ya un Garbage Collector, je me fiche des fuites mémoires)
- Ce n'est pas portable à 100%

"- On perd parfois en performances (C#/WPF par rapport a C++/QT par exemple) "

bah en même temps, que ton bouton mette 0.0314ms avec C# contre 0.0310ms avec C++/Qt pour s'activer c'est pas très important.

"- On prend parfois de mauvaises habitudes (Ya un Garbage Collector, je me fiche des fuites mémoires) "

En C++ c'est pareil et même pire, comme l'os libère toutes les ressources à la fin du processus, beaucoup de programmeur omettent les delete, c'est un comportement que j'ai vu sur plusieurs programmeurs.

Pour l'instant, avec le Framework 3.5, WPF arrive très vite a sa limite. Le SP1 arrange les choses mais c'est pas encore ça. J'ai vu des applications lourdes ramer comme pas possible et pourtant très bien codée. Ça devrait cela dit changer très bientôt avec le Framework 4.0.
La où C++/QT font pas le poid, c'est face à Expression Blend + Visual Studio + WPF ^^

Pour l'oublie des delete c'est pas faux ^^
Cela dit mettre les delete fait partie des bonnes habitudes que l'on perd avec le C#.

"- On prend parfois de mauvaises habitudes (Ya un Garbage Collector, je me fiche des fuites mémoires) "

En C++ c'est pareil et même pire, comme l'os libère toutes les ressources à la fin du processus, beaucoup de programmeur omettent les delete, c'est un comportement que j'ai vu sur plusieurs programmeurs. "

Heu... c'est faux, et facile de vérifier...
En C++ il est indispensable de faire des delete sur toute allocation mémoire. Car justement elle ne seront pas libéré par le programme.
On appel ca des fuite de mémoire. ou memory leak.
Et quand un programme a des fuite de mémoire, ben... tu reboot ton PC pour vider la mémoire vive.

Perso le garbage collector... bof bof, il fonctionne quand il veux et pas tout le temps comme il faut.

Le C# je connais pas, je sais que c'est l'équivalent du Java version Microsoft, donc un langague haut niveau (rien a voir avec le niveau de difficulté) et rien a voir avec le C++ non plus qui est un langage bas niveau.

Le problème de java et du C# est que c'est un langage interprété qui nécessite donc une VM java ou le CLR (Common Language Runtime) pour le C#, et donc forcement plus lent a l'exécution qu'un langage compilé.

Le mieux pour commencer a programmer, le Q basic sur calculatrice CASIO. c'est comme ca que j'ai commencé en tout cas.

Et forcement quand tu poussera plus loin pour faire des jeux video, l'apprentissage du C++ deviendra indispensable.
Car pour le moment seul les langage 'bas niveau' te permettent justement de jouer avec la mémoire pour optimiser des temps de traitement et surtout de jouer avec le GPU, Pixel et Vertex shader.

"Heu... c'est faux, et facile de vérifier...
En C++ il est indispensable de faire des delete sur toute allocation mémoire. Car justement elle ne seront pas libéré par le programme.
On appel ca des fuite de mémoire. ou memory leak.
Et quand un programme a des fuite de mémoire, ben... tu reboot ton PC pour vider la mémoire vive. "

Non, quand l'os kill le processus il libère toute les ressources, et heuresement, mais utiliser les delete est bien sur obligatoire pour quiconque se prétend programmeur.

"Perso le garbage collector... bof bof, il fonctionne quand il veux et pas tout le temps comme il faut. "

Bullshit ? Tu dois sûrement méconnaitre le fonctionnement d'un GC, il y a un article sur dvp qui explique bien la chose, google it.

"Le mieux pour commencer a programmer, le Q basic sur calculatrice CASIO. c'est comme ca que j'ai commencé en tout cas. "

C'est comme ça que tu as commencé certes, mais c'est loin d'être ce qui est recommandé pour débuter, le mieux étant de découvrir la prog avec un langage récent, utilisé, beau comme python.

"Le problème de java et du C# est que c'est un langage interprété qui nécessite donc une VM java ou le CLR (Common Language Runtime)

Ou pas, le compilateur JIT du CLR et la possibilité de directement faire du code non-managé, ainsi que les optimisations envers les libs windows font que C# n'est pas si lent que ça, certes plus lent que C++ mais il faut voir le temps gagné sur le développement, et je reposte ma vidéo de propagande : http://www.youtube.com/watch?v=TgChURF5fQE .

"Car pour le moment seul les langage 'bas niveau' te permettent justement de jouer avec la mémoire pour optimiser des temps de traitement et surtout de jouer avec le GPU, Pixel et Vertex shader. "

Affirmer ça c'est simplement méconnaitre les possibilités de C# et de .NET.

"Non, quand l'os kill le processus il libère toute les ressources, et heuresement, mais utiliser les delete est bien sur obligatoire pour quiconque se prétend programmeur. "

L'OS ne libère pas toujours toutes les ressources utilisées. Par exemple sous Unix si tu travaille sur des segments de mémoire partagée (IPC), ces segments restent en mémoire à la fin du programme (s'ils n'ont pas été détruits manuellement).

Ça a l'air sympa le C#, dommage que soit un langage propriétaire et non portable.

Pour le garbage collector et travail en ce moment sous FLEX, et l'action script fonctionne aussi avec un GC.
Et pour que le GC supprime réellement un élément de la mémoire il faut beaucoup de condition. Et on peut vite s'emmêler les pinceaux et ne pas comprendre pourquoi le GC ne supprime pas tel ou tel élément.
Ensuite c'est mon avis, mais un bon programmeur préfèrera gérer lui même les destructions d'éléments.

Ensuite dans tous les cursus de programmation les cours commenceront tout comme pour l'histoire, par le commencement.
Et l'assembleur... bien qu'il ne soit pas nécessaire d'y passer beaucoup de temps il est utile de savoir comment la mémoire fonctionne.

Je me permet de rappeler que le topic concerne un langage d'apprentissage. Je pense que les details du fonctionnement du GC n'aident pas vraiment OP a faire son choix.

Pour repondre aux problematiques du GC. Le probleme principale que l'on rencontre avec les garbages collectors sont lie aux temps de collectes (instant de collecte et duree de l'operation) qui sont difficile maitriser et a predire. C'est pour ca qu'on n'utilise pas de GC dans les systemes temps reel a contraintes fortes.

Cependant avoir un GC permet d'optimiser les placements memoires dans certaine mesure. Par exemple le GC a base de copy&sweep de ocaml permet d'avoir une fragmentation memoire faible. Des statistiques inteligentes d'acces aux objet peuvent permettre de les rapprocher en memoire. Mais je n'ai jamais vu d'implementation efficace de ca.

Justement on était en train de polémiquer sur le langage a recommander pour l'apprentissage, avec les avantages et inconvénients de chacun.
Et les avantage et inconvénients d'un GC peuvent déterminer de manière subjective le type de langage vers lequel se tourner pour débuter.

Pour moi, c'est comme la mécanique, pour bien connaitre il faut mettre les mains dans le cambouis, donc commencer par le plus basique. (les langages basique )