Back to AngelCode

Auto keyword behavior was changed?

AngelCode Affiliates

Started by Miss November 23, 2018 01:50 PM

8 comments, last by Miss 5 years, 4 months ago

Miss

183

Author

November 23, 2018 01:50 PM


void DoSomething()
{
	// No default constructor for object of type 'Foo'.
	// No appropriate opAssign method found in 'Foo' for value assignment
	auto f = Foo(Resources::GetSValue("something.sval"));

	// OK
	Foo@ f2 = Foo(Resources::GetSValue("something.sval"));

	// OK
	auto@ f3 = Foo(Resources::GetSValue("something.sval"));
}

class Foo
{
	Foo(SValue@ sval)
	{
	}
}

So it seems like the auto keyword is causing some issues here. The issue also doesn't show if I put int as the constructor param instead of SValue@. Might be related to this change?

Now the question is - is this change intended or is this a bug? We use the auto keyword like the first case all over our code. Seems like a big behavior change like this has to be a bug.. right?

This is tested on the latest SVN version.

WitchLord

4,834

November 23, 2018 04:08 PM

I'll need to investigate this.

The only expected change related to the 'auto' keyword is the one in revision 2497. However this should only have an effect if you use implicit handle types.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Miss

183

Author

November 26, 2018 02:56 PM

I don't think I'm using implicit handle types here, am I? Or is a constructor like that not actually returning a handle by default?

WitchLord

4,834

November 27, 2018 03:18 PM

The constructor is returning a handle, but the operation = without @ is a value assignment.

In a way it does make sense that 'auto f = ...' is different than 'auto @f = ...'

However, it doesn't make sense that the behaviour changes due to the constructor parameter, so there is definitely something wrong here. I haven't had the time to investigate it yet though.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

WitchLord

4,834

December 05, 2018 12:35 PM

I've identified the problem here. The code path that the compiler took to compile Foo(Resources::GetSValue("")) when GetSValue returned an object was different from when it returned a primitive. In one case the resulting type was a 'Foo@' and the other just 'Foo'.

However, instead of just fixing that I reflected a bit more on just what auto is supposed to do, and decided that auto should always prefer declaring the variable as a handle when possible as it is more efficient than as a value. So now, regardless of the right-hand expression being a 'Foo' or 'Foo@' the type of the variable will always become 'Foo@'.

Check-in of the fix is still pending. I'll do that as soon as possible (probably in the next 10 hours).

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

WitchLord

4,834

December 05, 2018 09:51 PM

checked in to revision 2568

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Miss

183

Author

December 07, 2018 09:41 AM

Thanks for the fix, however the same error is still appearing.

WitchLord

4,834

December 07, 2018 07:01 PM

Are you sure you retrieved and recompiled with the code changes?

The test case I added to test_feature matches your script, and before the fix it reproduced the problem.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game