Jump to content
  • Advertisement
Sign in to follow this  
Jason Goepel

Left-to-right Evaluation of opEquals method.

This topic is 656 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a bit of an odd construct in my application which is at odds with a change made in revision 2358 to the compiler.  I have registered a value type.  This value type contains configuration information for an application variable.  The assignment operator for this type modifies the underlying application variable, not the script variable.  For instance (something similar to this):

MyValueType& MyValueType::opAssign(double x)
{
    m_pApplicationVariable->SetValue(x);
    return *this;
}

MyValueType& MyValueType::opAssign(const MyValueType& x)
{
    opAssign(x.m_pApplicationVariable->GetValue());
    return *this;
}

I also have a comparison operator registered which compares a value to the application variable.

bool MyValueType::opEquals(double x)
{
    return m_pApplicationVariable->GetValue() == x;
}

My problem occurs when I try to compare an instance of this value type.  With the new left-to-right evaluation order for overloaded operators, a temporary variable is created for my value type object.  Unfortunately, the constructor isn't capable of setting up the configuration to my application variable, so when the assignment operator is called, my application generates an access violation.

// declared earlier: MyValueType my_val 

if (my_val == 3.5)

// generates...

MyValueType::MyValueType()  // temporary variable
MyValueType& MyValueType::opAssign(const MyValueType&inout)  // <-- crash
bool MyValueType::opEquals(double) // comparison with temporary variable
MyValueType::~MyValueType()  // destruction of temporary variable

How do you recommend I handle this?  Script writers cannot generate these objects directly.  Before using them they must be passed to an application function for configuration.

 

 

Share this post


Link to post
Share on other sites
Advertisement

Adding a working copy constructor to the MyValueType should resolve this.

Or make MyValueType be a reference type instead.

Share this post


Link to post
Share on other sites

Even in the case where an opEquals method takes a constant reference to an argument, the compiler will create a copy.  For large objects, this seems wasteful in the common case.  Would you consider a library, compile-time setting to not ensure left-to-right evaluation?  This would allow script writers to treat "==" like a direct call to opEquals.

 

In C++ all the overloaded operators in a class evaluate the argument list first, effectively making them evaluate right-to-left.  I understand that AngelScript already differs from C++ in the handling of operators, and some of those differences may justify an "always left-to-right" evaluation requirement. For instance, with a single opEquals overload, AngelScript will allow comparisons using that object when it appears on either the right or left side of the "==" operator; C++ only compiles if the object is on the left.

Share this post


Link to post
Share on other sites

Large objects should not be value types to begin, with so I don't worry too much about this wasting time. 

With AngelScript I try to keep a consistent behaviour as much as possible from the view point of the script writer. This does sometimes require sacrificing performance. This is a different mentality than that used to design C++, where the language is all about trying to provide as much power to the user as possible with as little overhead as possible. In C++ runtime behaviour is explicitly undefined in the standard to give the compiler vendors more freedom to optimize the output.

I'll consider adding a flag to relax the left-to-right evaluation, however. I don't think it would add too much complexity in to the compiler. 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!