   Transferring Returned reference from C++ in Script
  Hi,I went into a little problem when trying to wrap one of my C++ class in AS.I exposed a CEngineObject with a method GetPosition with this signature : "const CFloat2& GetPosition()const". (I made an Interface around AngelScript so I can't easily paste you declaration code, but I will if you really need it)Then I wrapped this exposed object in the script like that:class CObject{    CObject(CEngineObject@ _pEngineObject)    {   @m_pEngineObject = @_pEngineObject;    }    const CFloat2& GetPosition() const    {   return m_pEngineObject.GetPosition();    }    void SetPosition(const CFloat2&in _position)    {   m_pEngineObject.SetPosition(_position);    }    private CEngineObject@ m_pEngineObject;};And now when I compile this script I have the error : "Resulting reference cannot be returned. There are deferred arguments that may invalidate it.". So after reading the doc, I tried to figure out where would be the deferred argument, I finally traced into AS code to find out that my m_pEngineObject was copied and considered as a temporary argument. I can't see why m_pEngineObject has to be copied, I tried removing constness from everywhere thinking maybe, it copies the object to ensure consteness is respected?Anyway, it's a bit anoying that the only option I see is to return the info by value so a copy occurs. Is this temporary copy of m_pEngineObject is really necessary? if it is, why(i'm curious )? Is there any other option for me to return a reference on this position or do I have to return by copy in any cases?   
  References are tricky to deal with in a scripted environment. In AngelScript I need to make sure there is no way the reference can be invalidated before it is actually used, or you might get an application crash, or worse.The copy of the m_pEngineObject is necessary, because potentially the original m_pEngineObject handle might be destroyed while inside the method called on the handle. I will look into this scenario to see if I can find a way of allowing the script to be written like you want to do, without opening up a potential security issue. In the meantime, it would be best if you just return the CFloat2 by value, after all. You don't plan on changing the returned reference, so there is really no need to return it as a reference. The performance gain by keeping it as reference is probably not even noticeable.   ;  Well, of course I did the return by value for the time being as a Float2 is a small object and make a copy of it is not such a big deal, but it could be more damageable for bigger objects. Although I'm just starting on the Angelscript part of the game I'm working on, and I didn't profile it yet so I can't really say if calls to copy operator will be an issue, but I'm just worried.  I understand that calling a method on an invalid reference could cause security problems but I can't see how the handle carried by the class could be destroyed inside a const method called on it, maybe I'm missing something?   ;  Bigger and more complex objects should preferably be registered as reference types, so that they can be properly handled through object handles. The value types are only meant for objects that should be treated similarly to primitives.I can't think of any reason why anyone would want to destroy the object while inside the method, but want and accidentaly do so is quite different. It is quite easy to come up with a script that would invalidate a refernce, for example:class CObject{    CEngineObject @engine;    const CFloat2 &getRef() const    {   return engine.getRef();    }}class CEngineObject{   const CFloat2 &getRef() const   {  @g_obj.engine = null;  // <-- clear the engine handle in the global object  return val;   }   CFloat2 val;}CObject g_obj;void main(){   @g_obj.engine = CEngineObject();   x = g_obj.getRef().x; // <-- The returned reference would be invalid, if angelscript didn't protect the handles}While this example is quite contrived and will probably never happen in practice, I cannot go with 'probably'. I have to guarantee that under no circumstances a reference can be invalidated when it can still be used.   ;Bigger and more complex objects should preferably be registered as reference types, so that they can be properly handled through object handles. The value types are only meant for objects that should be treated similarly to primitives.Ok, that make perfect sense.I guess I'm not  quite in the right "scripting state of mind" yet and more  in a "C++ one" where you can have invalid references. But now that I think about what you're saying, I guess I probably prefer maximum insurance about reference validity too. Don't waste your time investing this particular case, you made your point, and I'm sure there is plenty of more important things for you to do Thank you for your enlightening answers, keep up the good work you're doing with AS.   