Jump to content
  • Advertisement
Sign in to follow this  
Miss

Auto keyword behavior was changed?

Recommended Posts

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.

Edited by Miss

Share this post


Link to post
Share on other sites
Advertisement

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.

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Sorry, you were right! It's fixed now. :)

I must've accidentally messed something up while updating our copy of the sources. Thanks!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!