Billy Charvet :
*En quoi est-ce anormal ?*
Ben on trouve tous les langages pour faire des scripts ASP.NET, aussi bien
C# et VB par défaut, que JScript, NetCobol ou FORTRAN, certains ont même
rendu possible de mettre dans des feuilles ASP.NET le langage Eiffel#,
ou bien l'assembleur x86 ("ASM.NET").
Vu le nombre de langages qui marchent en ASP.NET, le C++ n'y est pas,
ça fait clairement le langage oublié par .NET.
(Et c'est à Microsoft qu'il appartenait de faire un C++ en ASP, et il ne l'a pas fait...
Donc C++ n'est plus son fer de lance comme dans VC6, il s'efface un
peu au profit de C#)
Et alors? Le Managed C++ n'est pas forcément adapté à faire des trucs ASP.NET, ça n'empêche qu'il a plein d'autres utilités (notamment la capacité à faire la jonction entre les langages .NET utilisant la CLR et le code natif [API Win32 ou autre en C, code optimisé en assembleur, algorithme compilé en C++ permettant d'éviter d'utiliser des trucs garbage-collectés, ou plus simplement réutilisation de vieux code...] )
Donc non, franchement, d'accord le Managed C++ n'est pas le langage ultime pour MS (et ils ont bien raison : le C# est mieux si on veut faire un truc purement managed), mais il a en contrepartie tous les avantages du code natif. Je ne vois vraiment pas ce qui te permet de dire qu'il est inutile.
*Pas vraiment... ça reste du C++, y'a juste quelques __gc et autres à rajouter*
Sous C#, pas besoin. On apprend le langage et pas besoin
de lire une doc supplémentaire qui dise quoi faire en code managé.
Ces __gc feront préférer le C# au C++ pour programmer sous .NET.
(.NET est clairement un clone de Java d'ailleurs, donc C# est LE langage
qui mérite d'être utilisé, étant proche de Java)
Absolument, mais ça ne change rien à la vocation du C++ managé (qui est clairement _différente_)
*Le C++ aussi 
*
Etrange, mais il fait profil bas à côté des deux autres.
J'ai vu partout des docs pour se servir du compilo VB en ligne de commande,
mais pour Managed C++, rien ne m'est passé sous les yeux.
(Je parle uniquement de ce que j'ai vu bien en évidence, pour le reste y'avait sans
doute une doc qqpart)
Je ne pense pas que le Framework .NET soit fait pour compiler du C++ (je ne pense pas qu'ils s'amusent à mettre la STL dedans, par exemple), donc c'est normal qu'il n'y ait pas de doc sur qqch qui n'est pas implémenté
*A ton avis, pourquoi la team de SharpDevelop a-t-elle décidé d'ajouter le C++ dans la très prochaine version 1.0 ?*
Dommage, elle a commencé par VB 
Et Managed C++ n'a aucune chance face à du C++ natif sous un IDE aussi bon...
(Dev-C++ ?)
* lorsque tu n'utilises pas de pointeurs __gc, tu n'as aucun overhead lié au managed C++... donc tu fais ton interface avec le code .NET avec des __gc, et tu fais ton algorithme sans; évidemment, si tu n'as pas besoin d'interfaçage et que tu as un besoin impératif de vitesse, bah t'utilises pas de __gc et c'est tout aussi performant que du C++ normal...
* Dev-C++ est 100x moins bon
*Managed C++ est aussi fait pour le .NET...*
Je parle de la conception toute entière du langage, non du compilo.
Le C++ n'a pas été inventé pour .NET, et pour l'y adapter, ben forcément faut
ces __gc très moches. C# est né pour .NET, et ses mots-clés eux-mêmes
sont prévus pour .NET. Même chose pour VB (avec son remaniement en profondeur
depuis VB6)
Tu mets *un* __gc dans la définition de ta classe, et hop magie, toutes ses instances deviennent garbage-collectées... Ca n'a rien de moche, et tu n'as rien de plus à faire pour profiter de toutes les features de .NET.
(il y a aussi les attributs, mais là ça fonctionne exactement comme en C#)
*
