En C++, il y a de nombreuses façons d'écrire du code qui se compile, mais qui rapporte comportement indéfini (Wikipedia) . Existe-t-il quelque chose de similaire en C# ? Peut-on écrire du code en C# qui se compile, mais dont le comportement est indéfini ?
Comme d'autres l'ont mentionné, à peu près tout ce qui se trouve dans le bloc "unsafe" peut donner lieu à un comportement défini par l'implémentation ; l'abus des blocs "unsafe" vous permet de modifier les octets de code qui constituent le runtime lui-même, et donc tous les paris sont ouverts.
La division int.MinValue/-1 a un comportement défini par l'implémentation.
Lancer une exception et ne jamais l'attraper entraîne un comportement défini par l'implémentation -- terminer le processus, lancer un débogueur, etc.
Il existe un certain nombre d'autres situations en C# où nous sommes obligés d'émettre du code dont le comportement est déterminé par l'implémentation. Par exemple, cette situation :
http://blogs.msdn.com/ericlippert/archive/2006/04/06/odious-ambiguous-overloads-part-two.aspx
Cependant, les situations dans lesquelles un programme C# sûr et bien conçu a un comportement défini par l'implémentation devraient être assez rares.
Ouch, ce problème de surcharge est vraiment bizarre. Et moi qui pensais que DivisionByZeroException était le comportement attendu sur 1/0 . Quoi qu'il en soit, j'ajouterai demain...
@Eric : Je pensais que le coin que vous avez mentionné était le 1/0 habituel. J'ai fait des recherches et j'ai trouvé que c'est en fait int.MinValue/-1 .
En regardant le Article de Wikipedia sur le comportement indéfini En C#, les situations dans lesquelles un comportement indéfini se produit sont soit interdites, soit assorties d'une exception.
Cependant, dans un code non sécurisé, un comportement indéfini est possible, car il permet d'utiliser des pointeurs, etc.
Edit : On dirait que j'ai raison : http://msdn.microsoft.com/en-us/library/aa664771%28VS.71%29.aspx
A un exemple de comportement indéfini en c#
@Jeff Yates : Oui, je regardais son lien wikipedia pour déterminer quelles situations provoquent des comportements indéfinis.
Unspecified, plutôt que Implementation-Defined, du moins tel que le terme est utilisé dans la spécification C. Si la spécification considère une implémentation comme étant définie par l'implémentation, alors les implémentations conformes doivent fournir une documentation suffisante pour permettre au programmeur de savoir exactement comment elle se comportera. Une implémentation pourrait légitimement spécifier que (signed char)128 donnerait -126 pendant la première moitié de chaque phase de la lune, et -127 pendant la seconde moitié, mais seulement si l'implémentation détermine réellement la phase de la lune. Les implémentations ne peuvent pas simplement dire "donne une valeur arbitraire".
C'est juste non déterministe, pas indéfini. Vous avez toujours la garantie de savoir exactement ce que chaque thread va faire. Vous ne connaissez simplement pas l'ordre exact dans lequel les choses se produisent, et vous pouvez donc obtenir des résultats surprenants.
En général, je dirais non.
Utiliser une variable automatique avant qu'elle ne soit initialisée.
Toutes les variables doivent être initialisées. Si ce n'est pas le cas, une exception se produit.
Division par zéro
Une exception est levée.
Indexation d'un tableau hors limites
Une exception est levée
Comme l'a souligné Aequitarum Custos, vous pouvez utiliser du code non sécurisé. Mais encore une fois, ce n'est pas vraiment du C#, vous choisissez explicitement de sortir de l'environnement C#.
C'est pas C# unsafe { int* px1 ; int* px2 = &i ; F(out px1, ref px2) ; Console.WriteLine("*px1 = {0}, *px2 = {1}", *px1, *px2) ; // comportement indéfini } Oui, c'est écrit en C#.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
