tc donc le niveau de programmation est similaire a celui de Java/C# mais avec des perf voisine de C/C++.
Java/C# te garantisse une certaine sécurité. C/C++/D non. Même si D te propose d'avoir une meilleure sécurité, il n'y a aucune garantie, tu peux toujours manipuler des pointeurs qui font n'importe quoi, et rien ne t'empêche de le faire. Y'a une énorme différence entre : "t'es pas obligé" et "tu peux pas". Genre en tant qu'utilisateur, je peux obtenir un certain nombre de garantie de la part d'un exécutable .NET, alors qu'un exécutable écrit en D, si le concepteur a voulu faire un truc malveillant...
Je ne parle même pas du framework de sécurité sous-jacent présent dans .NET par exemple, qui permet d'attribuer des droits différents à chaque composant de la plateforme pour toutes les applis.
en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code
Faux problème : .NET a été conçu dès la base pour être utilisé en mode AOT (Ahead of Time) : la compilation JIT est faite une fois pour toute, l'exécutable natif est conservé en cache jusqu'à mise à jour.
franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows,
Windows ca tourne sur x86 mais aussi x64 et pleins de plateformes embarquées où est présent le framework .NET sous différentes formes.
De plus dans des scénario de remoting (Java RMI, .NET remoting), une compatibilité binaire reste indispensable.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Java/C# te garantisse une certaine sécurité. C/C++/D non. Même si D te propose d'avoir une meilleure sécurité, il n'y a aucune garantie, tu peux toujours manipuler des pointeurs qui font n'importe quoi, et rien ne t'empêche de le faire. Y'a une énorme différence entre : "t'es pas obligé" et "tu peux pas". Genre en tant qu'utilisateur, je peux obtenir un certain nombre de garantie de la part d'un exécutable .NET, alors qu'un exécutable écrit en D, si le concepteur a voulu faire un truc malveillant...
Je ne parle même pas du framework de sécurité sous-jacent présent dans .NET par exemple, qui permet d'attribuer des droits différents à chaque composant de la plateforme pour toutes les applis.
en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code
Faux problème : .NET a été conçu dès la base pour être utilisé en mode AOT (Ahead of Time) : la compilation JIT est faite une fois pour toute, l'exécutable natif est conservé en cache jusqu'à mise à jour.
franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows,
Windows ca tourne sur x86 mais aussi x64 et pleins de plateformes embarquées où est présent le framework .NET sous différentes formes.
De plus dans des scénario de remoting (Java RMI, .NET remoting), une compatibilité binaire reste indispensable.