Ist C # in Unity anders?

18

Verwendet Unity eine andere Version von C # oder ist das alles gleich? Es sieht anders aus als reguläres C #, enthält jedoch einige reguläre C # -Elemente.

kprovost7314
quelle
4
Welche Unterschiede sehen Sie?
Anko
Ich vermute, dass die Änderungen, auf die Sie sich beziehen, Framework-Unterschiede und nicht die C # -Sprache sind. In Unity3d verwenden Sie das .NET Framework (Via Mono) und Unity-spezifische Framework-Elemente mit der C # -Sprache.
Mike B
Es ist nur eine sehr alte Version. Wenn Sie die neueste Version von C # und Mono möchten und keine vorgefertigte Engine programmieren möchten, sollten Sie sich etwas wie monogame.net
Den
Ich habe leichte Unterschiede in der Bibliothek festgestellt, zum Beispiel gibt es in Unity eine Mathf-Klasse für mathematische Funktionen anstelle der Math-Klasse. Ich habe nicht darauf geachtet, ob es noch andere Unterschiede gibt, aber das ist derjenige, der auffiel.
Alex
@Alex System.Math ist noch verfügbar und anscheinend sogar schneller als UnityEngine.Mathf . Der einzige wirkliche Grund für die Verwendung der Unity-Version besteht darin, viele (Float-) Casts zu vermeiden. Dies geht zu Lasten der Leistung.
FlintZA

Antworten:

9

Wie in anderen Antworten angegeben, verwendet Unity 4.x eine modifizierte Version von Mono, die auf Mono 2.6 basiert

Zum größten Teil ist dies mit .Net 2.0 kompatibel , obwohl es mir nicht gelungen ist, eine Mono 2.6-spezifische Kompatibilitätsliste aufzuspüren.

Es sieht anders aus als reguläres C #, aber es gibt einige reguläre C # -Elemente.

Wie in einem der Kommentare zu Ihrer Frage erwähnt, liegt dies wahrscheinlich eher an der speziellen Skript-API von Unity als an der Sprache selbst.

In einem typischen Unity-Projekt ist beispielsweise viel Code in Unterklassen einer Klasse namens MonoBehavior enthalten. Dies sind Komponenten, die in GameObjects in der Unity Editor-Umgebung abgelegt werden. Diese Architektur führt in vielerlei Hinsicht zu C # -Code, der (für mich) anders aussieht als typischer C # -Code:

  • Bis zur Veröffentlichung von Unity 4 konnten diese Objekte nicht in Namespaces enthalten sein, daher befinden sie sich immer im globalen Namespace
  • Sie stellen Felder der Editor-Umgebung zur Verfügung, indem sie öffentlich gemacht werden (oder indem das SerializeField-Attribut verwendet wird, aber ich finde nur sehr wenige Leute, die dies verwenden), was zu einer ungewöhnlich großen Anzahl öffentlicher Felder in Klassen führt
  • Die Datenschutz- und Groß- / Kleinschreibungseinstellungen von Unity entsprechen nicht den von Microsoft, daher kann dies auch für einen "traditionellen" C # -Entwickler seltsam aussehen
  • Sie verwenden eine Reihe spezieller Methoden für diese Komponenten, z. B. Start und Update, die nicht wie erwartet außer Kraft gesetzt werden, sondern stattdessen über Reflektion abgerufen werden.

Praktisch ist die größte C # -Sprachenfunktion, die ich in der aktuellen C # -Version von Unity vermisse, die Unterstützung für asynchrone und verwandte Schlüsselwörter und Funktionen. Ein ähnliches Konzept in Unity sind Koroutinen . Diese werden auf dem Hauptthread ausgeführt, sind also nicht asynchron, ermöglichen jedoch das Aufteilen von Code mit langer Laufzeit über mehrere Frames. Multithreading auf niedrigerer Ebene wird weiterhin unterstützt.

FlintZA
quelle
2
Nur zur Verdeutlichung, asyncin C # ist es auch nicht asynchron wie in Multithread - es läuft auch auf dem Hauptthread. Die größten Unterschiede aus Sicht der Nutzung zwischen Coroutinen und Async sind die Zeiten, zu denen der Code ausgeführt wird.
Rhughes
Vielen Dank. Ja, asynchron! = Multithreading, obwohl es weitaus häufiger ist, Asynchronität zum Verbergen / Interagieren mit Multithreading-Operationen zu verwenden, als dasselbe mit Coroutinen zu tun. Ich habe eine Wrapper-Coroutine geschrieben, die delegierte Aufgaben in einem Threadpool startet, wodurch ich ein sehr ähnliches Maß an Flexibilität erhalte, aber es würde mir trotzdem nichts ausmachen, "richtigen" asynchronen Support zu haben. Natürlich wäre ein anständiger moderner GC noch besser;)
FlintZA
21

Unity 4 verwendet Mono 2.6 , eine vollständige Implementierung des .NET-Frameworks, einschließlich der C # -Sprache.

Ich bin mir nicht sicher, wie es anders aussieht, aber denke daran, dass Unity mehrere Sprachen unterstützt, die alle auf der gleichen Mono-Laufzeit arbeiten. Ist es möglich, dass Sie C # mit UnityScript verwechseln ?

Sergio
quelle
10
Außerdem entspricht Mono 2.6 in Bezug auf die Sprachfunktionen C # 3.0. In Mono 2.6.1 wurden C # 4.0-Funktionen hinzugefügt.
Cooper
Hier ist ein schöner Überblick über die Mono-Kompatibilität von Unity ab Version 4.1.2
Kelly Thomas,
Es hinkt nicht nur geringfügigen, sondern auch größeren Versionszuwächsen hinterher
Den
3

Unity verwendet reguläres C #.

Wenn Sie C # in Unity schreiben, werden Sie viele ihrer Bibliotheken verwenden, aber soweit ich weiß, ist in Unity alles möglich, abgesehen von den unten aufgeführten Unterschieden:

  • Speziellere .Net-Bereiche in Bezug auf Windows Forms und ASP sind durch Unity nicht zulässig.

  • Während Sie Visual Studio zum Bearbeiten und Kompilieren von Fehlern verwenden können, müssen Sie die Unity-IDE erstellen und ausführen.

  • Unity verwendet Mono, eine Open-Source-Implementierung von .Net, was bedeutet, dass es geringfügige Unterschiede gibt.

Pontus Magnusson
quelle
Erweitern Sie Ihr zweites Aufzählungszeichen, indem Sie mithilfe von UnityVS in Visual Studio debuggen . Microsoft hat die Entwickler kürzlich übernommen, damit sie das Plugin in naher Zukunft kostenlos veröffentlichen können.
Mrohlf
Sorry, aber es ist nicht annähernd normales C #.
Alper
0

Die Frage, ob sich die von Unity verwendete C # -Version von einer "normalen" C # -Version unterscheidet, wurde von anderen Posts beantwortet. Da Sie fragen explizit für bestimmte Elemente , die aus einer solchen regulären Version abweichen werde ich die nur geringfügigen Unterschied teile ich dann bemerkt , wenn die C # I Verwendung bei der Arbeit (dh C # 4.0 in Visual Studio 2010 und höher) und C # in der Einheit zu vergleichen, die ist, dass ich keine Standardwerte für Parameter in Funktionsdefinitionen verwenden kann. Das heißt, Sie müssen Ihr Projekt sorgfältiger einrichten, um eine neuere Version von C # zu verwenden. Weitere Erklärungen finden Sie unter diesem Link.

Edit: Ich lasse diese Antwort, da, soweit ich weiß, dies ein Missverständnis ist, das ziemlich vielen Menschen passiert.

Nessuno
quelle
Da diese Funktion erst in Version 4.0 zu C # hinzugefügt wurde und zuvor nicht vorhanden war, kann ihre Abwesenheit nicht wirklich als "Unterschied" zu "C #" bezeichnet werden.
ODER Mapper
1
C # Version 4 wurde im Jahr 2010 veröffentlicht. Ich glaube, viele Leute nutzen es und empfinden, wie ich, seine Abwesenheit beim Programmieren in Unity.
Nessuno
Sind Sie sicher, dass Sie keine Standardwerte verwenden können? Ich bin mir ziemlich sicher, dass ich ...
NPSF3000
Ich habe es versucht und es wird nicht mit einer Meldung kompiliert, dass ich keine Standardwerte verwenden kann. Verwenden Sie eine spezielle Version von Unity? Wie die Pro-Version?
Nessuno
1
Sie können absolut Standardwerte verwenden, und es hat nichts mit Pro oder Nicht-Pro zu tun. Unity und MonoDevelop haben eine merkwürdige Beziehung. Die automatisch generierten Projekte in MonoDevelop werden häufig auf frühere Versionen von C # gesetzt, die keine Standardwerte unterstützen. Wenn Sie diese Einstellung im Projekt ändern, funktioniert dies jedoch einwandfrei. Wenn Sie die Kompilierung in MonoDevelop ignorieren und einfach zu Unity zurückkehren, werden Sie feststellen, dass Unity sich nicht über die Standardparameter beschwert.
MrCranky