koobas.hobune.stream
Does C# use #pragma strict?
I've noticed I see #pragma in JavaScript but don't think I've seen it in C#. Is this a Java only thing? When I'm adapting a script from Java to C#, I should omit #pragma strict?
Pragma strict is a way to tell javascript to "be a stricter compiler". That is, it should throw errors when you try to do dumb things that javascript allows. C# is by nature "stricter" and doesn't need to be told to do that
stricter isn't the right term. Precisely it requires you to define the type of each variable such as int, double, etc in javascript.
Java isn't an abbreviation for Javascript, it's an entirely different language, which is not used in Unity.
Actually, no. The C# compiler doesn't understand the pragma "strict". The MS C# compiler actually only understands two pragmas. Not sure if the Mono compiler has any additional ones but "strict" certainly isn't one of them. Unknown pragmas are usually ignored, however to keep the code clean you shouldn't add it to a C# script.
Like Eric already said JavaScript is not Java. You really shouldn't confuse those two languages. Java has no relation to Unity at all (with the small exception of Android since android apps run in a Java VM). Unity's JavaScript is actually called UnityScript (internally and more and more externally as well). UnityScript just has a JavaScript-like-syntax but is actually a complete seperate language. Unity called it "JavaScript" only for marketing purposes ^^
Thanks for the clarification
When discussing "JavaScript" for Unity, is it better to refer to it as UnityScript, then?
@LeftyTwoGuns: Yes definitely ;) However calling it "JavaScript" is also fine... It's actually wrong but it's been like this for years now, so that can't be fixed anymore :)
Internally it's called UnityScript. Even the compiled assembly names of your "javascript"-scripts are called "assembly-unityscript-firstpass.dll" and "assembly-unityscript.dll"
As far as I can tell C# does not support #pragma strict. See reference here.
C# by nature uses strong typing. Though you can still use the var type to tell the compiler to infer the type.
var is actually not a type. It's just syntactical sugar ;) The type is still staticly declared. If the type can't be deter$$anonymous$$ed at compiletime you'll get an error.
@Bunny83 the term "syntactic sugar" implies that it does not do anything useful. I would argue var does in fact do something that nothing else can do, and it is therefore useful if the API and return types of a library are unknown to the user (rare I know). I've seen it used for obscure classes whose API does not need to be known. It's use is similar to that of auto in C++ as you described, but I believe Bored$$anonymous$$ormon understood that since he said compiler, not runtime. Sorry for the rant ;)
@Andy$$anonymous$$artin458: Why does "syntactic sugar" implies it's not useful? o.O What i said is that var is not a seperate type and the variable is still strong typed. In the answer it sounds like "var" is an exception.
ps: If syntactic sugar is not useful we would all code in assembler and IL, right? ;)
pps: "var" does in fact nothing special which can't be done in another way. It just saves you from writing out the type name. In the end (in the compiled form / IL) you'll see no difference between:
var tmp = 5;
or
int tmp = 5;
var should never be used to "hide" obscure classes. Code should be readable. You can use var when it's clear what type the variable will get:
//positive examples:
var speed = 5.0f; // float
var vec = Vector3.Project(A,B); // Vector3
var myList = new List<string>(); // List<string>
// negative example:
var someVar = someFunction(); // ???
// in such cases it's way better to do:
RaycastHit hit = someFunction();
