Sign in to follow this  
Jason Goepel

Unsafe const &in

Recommended Posts

Jason Goepel    797

Turning on unsafe references allows in-out references to be used for primitives and value types, meaning a function prototyped like:

   void func(const ValueType &inout x) 

will pass a reference to the function and not make a copy.  This works just fine, but it seems like this should also work for a constant in reference:

   void func(const ValueType &in x)

 

However, a copy will always be made for a value type passed to an in reference, even if the in reference is constant.  This construct causes my users confusion, so I took a quick look at trying to modify the code in asCCompiler::PrepareArgument. The solution looks like it would be more complicated than simply changing what PrepareArgument does in response to an in reference.  It looks like there are a lot of checks in the compiler that check the reference type and make assumptions about what an argument is allowed to be.  Is this an accurate understanding?

 

It seems like the checks against the reference type in asCCompiler::MoveArgsToStack would also need to be modified, but I don't quite grasp what the new tests would be.

 

I would appreciate any help, thanks.

 

(P.S. It would also be nice to have a constant in-out reference be able to construct a temporary object if the argument passed in is found in the parameter type's constructor)

 

Share this post


Link to post
Share on other sites
WitchLord    4678

If you are using unsafe references then there is really no use for 'const ValueType &in'. It would be better to simply use 'const ValueType &'. If you want to customize the library I suggest you change it so that &in is modified to &inout when registering the function and unsafe references is turned. This way you don't have to make any changes in the compiler itself.

 

'const ValueType &in' should really be thought of passing the argument by value (rather than as a const reference). I already have plans to change this sometime in the future to make it clearer to the end-user.

Share this post


Link to post
Share on other sites
Jason Goepel    797

I have followed your suggestion and changed const &in to become const &inout.

 

I do find the automatic construction of a temporary variable passed to a const &inout parameter useful, so I have attempted a modification to make that work.  I have attached it as a patch.  It seems to work in my tests, but I am not sure if I am properly handling all cases.  If you don't incorporate this change officially, would you mind looking it over to see if I missed anything obvious to you?

 

Thanks

Share this post


Link to post
Share on other sites
WitchLord    4678

Just reviewed the code. So far it seems you've thought of most of the things that needed to be modified. 

 

To check if anything was broken in the process you'll need to run the regression tests (from the svn /tests/test_feature). You should preferably add new test cases for testing the implicit conversions in case of const &inout and unsafe references (e.g. in test_unsaferef.cpp).

 

One thing to remember (I'm not sure if you already thought of this or not) is that the const &inout should be referring to the actual object if the object is a ref type. This because it is possible that the function that receives the const reference may store a handle to it for later use. For value types it is not so important, as the function isn't allowed to keep the reference.

 

I may add this patch in sometime in the future with an engine property to allow users to turn it on or off as desired. 

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