Problem with code in Unity 3.4, Pragma Strict won't turn off!

Unity Engine
1

So I updated to 3.4 and now I’m getting all sorts of error messages with my code. It seems that pragma strict was somehow turned on without me writting it in the code.

Is there a way to turn it off? Is this a known error with 3.4?

2

pragma strict basically states that you need to define things before you use them. I believe that they instituted the pragma strict to clear up issues caused by dynamic typing. This will force you to type things. (honestly it is a good practice to define what things are so compilers won’t get confused.)

I have noticed that some typing issues came up in JS, but not near as strict as CS.

Can you be specific about issues?

3

yes, specifically just about everything in my code is broken, because I used dynamic typing as an easy way to code. But it looks as though I’m doomed to type everything anyhow.

Do you know of a way to turn on dynamic typing or is this the way it will have to be?

Thanks for your reply.

4

you can’t turn it off, and its saving you from your own stupidity (I mean that as a phrase not insult)

  1. it will result in a lot less bugs in your code
  2. it will run up to 50% faster code
  3. it is very easy to declare your variables properly

It should have remained pragma strict from the beginning tbh, I’m not sure why it became optional at all.

5

#pragma strict is only enforced for iOS/Android publishing. This was always the case anyway, the only difference now is that it’s enforced at compile time, instead of when you make a build. If you do web/Mac/PC publishing, you can use dynamic typing to your heart’s content (if you insist). So nothing really has changed regarding #pragma strict.

Please stop writing this. :slight_smile: #pragma strict doesn’t have anything to do with declaring variables, properly or otherwise.

#pragma strict

function Start () {
	// Compiles and runs just fine.  Hella slow, but it works.
	var foo;
	foo = 4;
	print ("foo is " + foo + " and is of type " + typeof(foo));
	foo = "abc";
	print ("foo is " + foo + " and is of type " + typeof(foo));
	
	// Please do this instead, it is much faster, and is type-safe.
	// Type inference permanently casts the variable as an int.
	// In no way is this related to dynamic typing, at all.
	// Type inference != dynamic typing.
	var bar = 2;
	print ("bar is " + bar + " and is of type " + typeof(bar));
	// bar = "abc"; // Won't compile, bar is an int and can't be a string
	
	// This is 100% identical to the code above.
	// It is not faster in any way, shape, or form.
	// It is exactly the same. 
	var bar2 : int = 2;
}

–Eric

6

Thanks for everyone’s response.

I have been compiling and running my games and even making money off them on iTunes, several thousand dollars worth, back when I compiled with Unity 3.3 by using dynamic typing!!!

It really isn’t such a big deal, I just have about 200 errors that I have to deal with now and rewrite the code. And that it took me two days just to figure out that #pragma strict was now being enforced automatically. I thought it was worse than that! I’m happy it’s nothing serious.

7

That would be very odd, since any time I accidentally had dynamic typing in an iOS project, Unity would generate “Error building Player because scripts had compiler errors” messages when building, and would refuse to create the build until I fixed them.

–Eric

8

I’m still not clear on it eric. Why is strongly typing your variables not any faster? when I started to use #pragma strict and strongly typed my variables, everything got faster.

9

Variables are always strongly typed in Unity, as long as you give the compiler a value to infer the type from.

var foo = 5;
var foo : int = 5;

That’s 100% identical. In the first case, the compiler sees that you’re using an int, so foo is strongly typed as an int. That’s not dynamic typing, it’s type inferencing. C# works exactly the same way:

var foo = 5;
int foo = 5;

Again, 100% identical. There is no speed increase in either case; they are the exact same code. This is easy to prove by benchmarking it, or looking at the generated CIL code. The only way you’d ever see a speed difference is if you did this:

var foo;
foo = 5;

In this case the type is figured out an runtime instead of compile time (and the difference is a hell of a lot more than 50%, it’s more like 2000%).

–Eric

10

I have an idea for a program that needs strict off on android.

Basically I would like to write an advance paint program on android and pc that allows users to directly write code for filters. The user language would be something custom and restricted but internally it would translate to Javascript functions that would be returned from eval(), I could generate il directly with Reflection.Emit, but that would be infinitely harder.

I can’t get as far as finding out if eval works on Android (though I read it is disabled), because I can’t seem to create a typed variable to hold an eval created function. And with strict on, I can’t call through an untyped variable.

If I create a variable holding a function that seems to have the same signature as an eval returned function, I still get a cast error when I try to assign to it from an eval.

So to sum up:

  1. there ARE situations where strict is onerous.
  2. With strict on I can’t have:
    var aFunction;
    //code that sets aFunction from an eval…
    i=aFunction(j); // because I can’t invoke an untyped var
  3. with strict on I can’t:
    var aFunction=function(i:int):int{return 0;}; //empty function to set the type
    //…
    aFunction = eval(“function(i:int):int{return (i0x3fffffff)+0x3847827;}”); //this causes a cast error even on the PC because somehow runtime generated functions are different
11

Er on 3) I shouldn’t have said with strict on.

It’s better to say
3) even with strict off I can’t use all typed variables:
var aFunction=function(i:int):int{return 0;}; //empty function to set the type
//…
aFunction = eval(“function(i:int):int{return (i0x3fffffff)+0x3847827;}”); //this causes a cast error even on the PC because somehow runtime generated functions are different

12

I’ll also mention that evoking a function, any function, through an untyped variable on the PC is about 200 times slower, which is annoying.

13

Correction again, that’s in the debugger. In a regular build it’s about 70 times slower. Still onerous but usable for plenty of things.

14

I’ll get an improvement of 2000% or a reduction?

15

A reduction. The point is that dynamic typing is slow.

–Eric

16

Cool. Just wanted to be sure. :stuck_out_tongue: