• 10
• 12
• 12
• 14
• 15

# Tepm object on multiple sub-expression

## Recommended Posts

I had a string class (value type) defined like:

BAIY_LOCAL void
CopyConstructString(IN const stringEx& rhs, OUT stringEx* pThis)
{
new(pThis) stringEx(rhs);
}

BAIY_LOCAL stringEx&
StringShlStr(IN const stringEx& rhs, IN OUT stringEx& obj)
{
BEGIN_EXP_GUARD_BLOCK;
obj.detach_if_static();
obj << rhs;
END_EXP_GUARD_BLOCK;
return obj;
}

BAIY_LOCAL stringEx&
StringShlInt32(IN const INT32 rhs, IN OUT stringEx& obj)
{
BEGIN_EXP_GUARD_BLOCK;
obj.detach_if_static();
obj << rhs;
END_EXP_GUARD_BLOCK;
return obj;
}

// ...
r = pENGINE->RegisterObjectMethod("stringEx", "stringEx& opShl(const stringEx &in)", asFUNCTION(StringShlStr), asCALL_CDECL_OBJLAST); assert(r >= 0);
r = pENGINE->RegisterObjectMethod("stringEx", "stringEx& opShl(const int32)", asFUNCTION(StringShlInt32), asCALL_CDECL_OBJLAST); assert(r >= 0);



And when I execute the script:

void main(stringEx& lhs)
{
lhs << "abc" << 456;
}


with:

stringEx lhs = "123";

// ...
pCTX->SetArgObject(0, &lhs);
r = pCTX->Execute();



The return value of "lhs" is "123abc", not "123abc456". i.e.: A temporary string obj created by the engine (by using CopyConstructString) after the first sub-expression (lhs << "abc"), And then, the second sub-expression (tempStr << 456) executed on the temp string object.

This behavior is not what we want because the "operator<<" just return a self reference clearly in above codes. When return a self reference, we mean "don't create a temporary object".

So, how could I let the engine know that don't create a temp obj, just using the self reference instead?

PS: I have been customized the engine at startup by:

#define TRUE 1
//...
asIScriptEngine* const pENGINE = asCreateScriptEngine();
pENGINE->SetMessageCallback(asFUNCTION(MessageCallback), 0, asCALL_CDECL);

pENGINE->SetEngineProperty(asEP_ALLOW_UNSAFE_REFERENCES, TRUE);
pENGINE->SetEngineProperty(asEP_USE_CHARACTER_LITERALS, TRUE);
pENGINE->SetEngineProperty(asEP_MAX_STACK_SIZE, 1048576);
pENGINE->SetEngineProperty(asEP_BUILD_WITHOUT_LINE_CUES, TRUE);



Please notice that the "asEP_ALLOW_UNSAFE_REFERENCES" option has been turned on (set to 1) as soon as the engine has been created.

BTW: If we write the script as:

void main(stringEx& lhs)
{
lhs << "abc";
lhs << 456;
}


Then everything work fine now. But this syntax is inconvenient when we need to format a complex string.

##### Share on other sites

Plus the issues that we have discussed here: https://www.gamedev.net/topic/685707-why-asep-allow-unsafe-references-is-unsafe/

We need a macro to let us define a macro (something like: "AS_USE_RAW_REFERENCE"?) to make the engine treat the reference "as it is" (i.e.: don't make copy or AddRef on it). Just like what c++ does. :rolleyes:

##### Share on other sites

I'll look into this.

##### Share on other sites

OK, a lot of thanks, it's very important for me :D

After some investigation, I find this may something related with the flag "type.isVariable" of asCExprContext. This flag be set to false in several methods of asCCompiler, for example:

asCCompiler::CompileOperatorOnHandles
asCCompiler::CompileCondition
asCCompiler::CompileExpressionPostOp


But I have not figured out how to modify it to add the "AS_USE_RAW_REFERENCE" macro... :blink:

##### Share on other sites

Hi Andreas, is there any chance to fix this issue in future version?  :(

##### Share on other sites

There is a chance. But I don't think it will be a trivial change, and it will most likely take a while before I get to fix this.

##### Share on other sites

I understand that this is not easy, because I have tried to fix it. But I believe this may be the most serious problem for AngleScript language. So I think it is worth some effort in this issue. :)

##### Share on other sites

Hi Andreas, Is this problem likely to be fixed in the next release?

Thanks :-)

Edited by ASBai

##### Share on other sites

Hi ASBai,

thanks for reminding me of this topic. I cannot promise anything, but I will definitely bump up the priority on fixing this problem.

I'm still far away from releasing the next version, and it is quite possible I will find the time to include an improvement for this too.

Regards,
Andreas

##### Share on other sites

Ok, lot of thanks for your quickly response and the great effort on this beautiful language.

:-)