I have an object registered like:

eng->RegisterObjectType("MyType", sizeof(MyType), asOBJ_VALUE | asOBJ_POD);
eng->RegisterObjectBehaviour("MyType", asBEHAVE_CONSTRUCT, "void f(double)", ...

I have another function registered like:

eng->RegisterGlobalFunction("void myFunc(const MyType& x)", ...

I call the function in the script:

myFunc(60.0);

I get a compile error:

No matching signatures to myFunc(const double)

Candidates are:

void myFunc(const MyType&inout)

However, if I had registered the function like:

eng->RegisterGlobalFunction("void myFunc(const MyType&in)", ...

the engine properly constructs a new instance of MyType and passes it by reference to the function.

It seems like "const &inout" could have the same behavior as "const &in", but this is obviously not the case. Is there a reason for the difference?

Thanks

This is correct.

"const &inout" doesn't do the implicit cast because the function expects a reference that it can modify and that this modification is supposed to have an effect on what the caller sees.

"const &in" on the other hand is meant as an input value and is pretty much identical to passing the argument by value except for the calling convention, which is why the implicit cast is performed.

Regards,

Andreas

How can a function expect to modify a constant reference? With out the "const" modifier, I agree, &inout cannot perform an implicit cast, but "const &inout" seems very much like the C++ constant reference, which will call an object's constructor if the caller passes an argument from which the object can be constructed.

Personally, it does seem like "const" contradicts the "out" part of "&inout", but "&inout" is what you get when you use just "&". Perhaps, the rule could be a bit more complex?

Object &x ==> Object &inout x

const Object &x ==> const Object &in x

Thoughts?

somehow I missed the const part.

You're absolutely right that the function cannot modify the value due to the const, and in this case I don't see any harm in allowing the implicit conversion. I'll look into the necessary changes to the compiler and perhap implement it for the next release.

I suppose implicit conversion does not work for registered types without the rvalue having registed a cast to the lvalue.

Registering the following constructor allows a double to be passed to to a function which expects a const Mytype&in

eng->RegisterObjectBehaviour("MyType", asBEHAVE_CONSTRUCT, "void f(const double&in)", ...

but the registering the next constructor does not permit the same behavior for a string

eng->RegisterObjectBehaviour("MyType", asBEHAVE_CONSTRUCT, "void f(const string&in)", ...

The construction of the object works, not not the implicit conversion.

I notice a TODO in the ImplicitConvObjectValue function which seems to address this issue. (as_compiler.cpp: line 5171)

asUINT asCCompiler::ImplicitConvObjectValue(asSExprContext *ctx, const asCDataType &to, asCScriptNode * /*node*/, EImplicitConv convType, bool generateCode)
{
	asUINT cost = asCC_NO_CONV;

	// If the base type is still different, and we are allowed to instance
	// another object then we can try an implicit value cast
	if( to.GetObjectType() != ctx->type.dataType.GetObjectType() )
	{
		// TODO: Implement support for implicit constructor/factory
...

Do you remember any special concerns or complications that may have prevented you from implementing this originally? I may attempt to implement it myself.

Thanks.

I don't think there is anything preventing this. I just haven't had the time to implement it myself, and I haven't prioritized it since there is an alternative way of doing the implicit conversions it with value cast behaviours.

I noticed the value case behaviours, but I find those undesirable in this situation. I have many classes that I would like to construct with a string, and I think it would be too much maintenance to add implicit value casts for all of those types into the string class. I will attempt to implement it myself, and I'll let you know how it goes.

Thank you.