# Type with asOBJ_REF tries to copy on &in

## Recommended Posts

Posted (edited)

I have a type that I defined like this:

r = m_engine->RegisterObjectType("SValueBuilder", 0, asOBJ_REF); assert(r >= 0);

Now consider the following AS code:

void Test1(SValueBuilder &in builder)
{
Test2(builder);
}

void Test2(SValueBuilder &in builder)
{
}

This actually throws this error at me which I did not expect, considering it's passed as a reference:

[WRN] [11:41:38] ERR  : scripts/main.as (line 3, column 8)
[WRN] [11:41:38]      : No appropriate opAssign method found in 'SValueBuilder' for value assignment
[WRN] [11:41:38]      : Previous error occurred while attempting to create a temporary copy of object

Why is it trying to copy the object if it's passing it as a reference? Is this a bug, or am I overlooking something?

Edited by Miss

##### Share on other sites

I recall seeing in code that "&in" parameters are copied to make sure they are not used for output as well and checking the docs it does actually mention this:
https://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_func_ref.html
"Input references are written as &in. As the reference is meant as input only, the actual value it refers to normally is a copy of the original so the function doesn't accidentally modify the original value. These are not commonly used, as they provide little benefit over passing arguments by value. Only in some circumstances can the performance be improved, especially if the parameter is declared as const too."

##### Share on other sites

Ah, I see. I still think the difference between &in, &out, and &inout is a strange concept to have in the language, but maybe that's just me. By that paragraph, I assume "const Type &in x" doesn't copy the object, because it's const anyway?

##### Share on other sites
3 hours ago, Miss said:

Ah, I see. I still think the difference between &in, &out, and &inout is a strange concept to have in the language, but maybe that's just me﻿. By that paragraph, I assume "const Type &in x" doesn't copy th﻿e object﻿, bec﻿ause it's﻿ const any﻿﻿wa﻿y?

I agree. But unfortunately it is necessary to keep compatibility with C++ native functions while still providing safe memory management in the scripts.

The compiler will avoid a copy of 'const type &in' when it is possible to guarantee the lifetime of the object, for example the object is a local variable. The copy is still made when the life time is not guaranteed, e.g. when being an element in an array.

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 10
• 15
• 22
• 19
• 46