C # est-il différent dans Unity?

18

Unity utilise-t-il une version différente de C #, ou est-ce la même chose? Il semble différent du C # normal, mais il contient des éléments C # réguliers.

c# unity

— kprovost7314
source

4

Quelles différences voyez-vous?

— Anko

Je soupçonne que les changements auxquels vous faites référence sont des différences de cadre et non le langage C #. Dans Unity3d, vous utilisez le framework .Net (Via Mono) et les éléments de framework spécifiques à Unity avec le langage C #.

— Mike B

C'est juste une très ancienne version. Si vous voulez la dernière version de C # et Mono et que vous souhaitez programmer plutôt que de scripter un moteur prédéfini, envisagez quelque chose comme monogame.net

— Den

J'ai remarqué de légères différences de bibliothèque, par exemple dans Unity il y a une classe Mathf pour les fonctions mathématiques, au lieu de la classe Math. Je n'ai pas fait attention s'il y a d'autres différences, mais c'est celle qui s'est démarquée.

— Alex

@Alex System.Math est toujours disponible et est apparemment plus rapide que UnityEngine.Mathf . Donc, la seule vraie raison d'utiliser la version Unity est d'éviter beaucoup de lancers (flottants) .. au prix de certaines performances.

— FlintZA

9

Comme indiqué dans d'autres réponses, Unity 4.x utilise une version modifiée de Mono basée sur Mono 2.6

Pour la plupart, cela est compatible avec le .Net 2.0 , même si je n'ai pas réussi à retrouver une liste de compatibilité spécifique à Mono 2.6.

Il semble différent du C # normal, mais il contient des éléments C # réguliers.

Comme mentionné dans l'un des commentaires sur votre question, cela est probablement dû à l'API de script particulière d'Unity plutôt qu'au langage lui-même.

Par exemple, beaucoup de code dans un projet Unity typique est contenu dans des sous-classes d'une classe appelée MonoBehavior. Ce sont des composants qui sont déposés sur GameObjects dans l'environnement Unity Editor. Cette architecture conduit à un code C # qui semble différent du code C # typique (pour moi de toute façon) de plusieurs façons:

Jusqu'à la sortie d'Unity 4, ces objets ne pouvaient pas être contenus dans des espaces de noms, ils sont donc toujours dans l'espace de noms global
Ils exposent des champs à l'environnement de l'éditeur en les rendant publics (ou en utilisant l'attribut SerializeField, mais je trouve que très peu de gens l'utilisent), ce qui conduit à un nombre inhabituellement élevé de champs publics sur les classes
Les conventions de confidentialité et de cas de Unity ne suivent pas celles de Microsoft, donc cela peut aussi sembler étrange à un développeur C # "traditionnel"
Ils utilisent un certain nombre de méthodes spéciales sur ces composants, telles que Démarrer et Mettre à jour, qui ne sont pas des remplacements comme on pourrait s'y attendre, mais qui sont accessibles à la place par réflexion.

En pratique, la plus grande fonctionnalité du langage C # qui me manque dans la version C # actuelle d'Unity est la prise en charge de async et des mots clés et fonctionnalités associés. Un concept similaire dans Unity est celui des coroutines . Celles-ci s'exécutent sur le thread principal, elles ne sont donc pas vraies asynchrones, mais permettent au code de longue durée d'être divisé sur plusieurs trames. Le multithreading de niveau inférieur est toujours pris en charge.

— FlintZA
source

2

Juste pour clarifier, asyncen C # ce n'est pas non plus vrai asynchrone comme en multi-thread - il fonctionne également sur le thread principal. Du point de vue de l'utilisation, les plus grandes différences entre les coroutines et l'async sont les heures d'exécution du code.

— rhughes

Merci. Ouais async! = Multithread, bien que je dirais qu'il est beaucoup plus courant d'utiliser async pour cacher / interagir avec des opérations multithread qu'il ne le serait avec les coroutines. J'ai écrit une coroutine wrapper qui démarre les tâches de délégué sur un pool de threads, ce qui me donne un niveau de flexibilité très similaire, mais cela ne me dérangerait pas d'avoir un support asynchrone "approprié". Bien sûr, un GC moderne décent serait encore mieux;)

— FlintZA

21

Unity 4 utilise Mono 2.6 , qui est une implémentation complète du framework .NET, y compris le langage C #.

Je ne sais pas à quoi cela ressemble, mais gardez à l'esprit que Unity prend en charge plusieurs langues, qui fonctionnent toutes sur le même runtime Mono. Est-il possible que vous confondiez C # avec UnityScript ?

— Sergio
source

10

Pour ajouter, Mono 2.6 est équivalent à C # 3.0 en termes de fonctionnalités de langage. Mono 2.6.1 a commencé à ajouter des fonctionnalités C # 4.0.

— Cooper

Voici un bon aperçu de la compatibilité mono d'Unity à partir de la v4.1.2

— Kelly Thomas

Il est en retard non seulement mineur, mais d'un incrément de version majeur: mono-project.com/Release_Notes_Mono_3.4

— Den

3

Unity utilise le C # normal.

Là encore, lorsque vous écrivez C # dans Unity, vous utiliserez beaucoup de leurs bibliothèques, mais pour autant que je sache, tout ce qui est possible en C # est possible dans Unity, à l'exception des différences répertoriées ci-dessous:

Les domaines plus spécifiques de .Net relatifs aux formulaires Windows et ASP sont interdits via Unity.
Bien que vous puissiez utiliser Visual Studio pour les erreurs d'édition et de compilation, vous devez créer et exécuter dans l'IDE Unity.
Unity utilise Mono qui est une implémentation open source de .Net, ce qui signifie qu'il y a de légères différences.

— Pontus Magnusson
source

Pour développer votre deuxième puce, vous pouvez également déboguer dans Visual Studio en utilisant UnityVS . Microsoft a récemment acquis les développeurs afin qu'ils lancent gratuitement le plugin dans un proche avenir.

— mrohlf

Désolé mais ce n'est pas du tout le C # habituel.

— Alper

0

La question de savoir si la version C # utilisée par Unity est différente d'un C # "normal" a été répondue par d'autres articles. Étant donné que vous demandez explicitement certains éléments qui pourraient différer d'une version aussi régulière, je partagerai la seule différence mineure que j'ai remarquée lors de la comparaison du C # que j'utilise au travail (c'est-à-dire C # 4.0 dans Visual Studio 2010 et supérieur) et C # dans Unity, ~~qui est que je ne peux pas utiliser les valeurs par défaut pour les paramètres dans les définitions de fonction.~~ c'est-à-dire que vous devez configurer votre projet plus soigneusement afin d'utiliser une version plus récente de C #. Voir ça lien pour plus d'explications.

Edit: Je laisse cette réponse car pour autant que je sache, c'est un malentendu qui arrive à beaucoup de gens.

— Nessuno
source

Comme cette fonctionnalité n'a été ajoutée à C # que dans la version 4.0 et n'était pas présente auparavant, son absence ne peut pas vraiment être qualifiée de "différence" à "C #".

— OR Mapper

1

C # Version 4 est sorti en 2010. Je pense que beaucoup de gens l'utilisent et ressentent, comme moi, son absence lors de la programmation dans Unity.

— Nessuno

Êtes-vous sûr de ne pas pouvoir utiliser les valeurs par défaut? Je suis presque sûr de l'avoir fait et de l'avoir ...

— NPSF3000

Eh bien j'ai essayé et ça ne se compilera pas avec un message me disant que je ne peux pas utiliser les valeurs par défaut. Utilisez-vous une version spéciale d'Unity? Vous aimez la version pro?

— Nessuno

1

Vous pouvez absolument utiliser des valeurs par défaut, et cela n'a rien à voir avec pro ou non-pro. Unity et MonoDevelop ont une relation étrange. Les projets générés automatiquement dans MonoDevelop sont souvent définis sur des versions antérieures de C # qui ne prennent pas en charge les valeurs par défaut. Cependant, si vous modifiez ce paramètre dans le projet, cela fonctionnera très bien. Si vous ignorez la compilation dans MonoDevelop et revenez simplement à Unity, vous remarquerez que Unity ne se plaint pas des paramètres par défaut.

— MrCranky