Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Jason Goepel

Member Since 15 May 2013
Offline Last Active Nov 24 2014 08:29 AM

Topics I've Started

Multithreading - Creating a Module

04 November 2014 - 03:25 PM

I know that building multiple modules in separate threads that belong to the same engine is "thread safe" because the engine will only allow building one module at a time.

 

It looks like if multiple threads are calling "asIScriptEngine::GetModule" and "asIScriptModule::Discard" at the same time they calling code should acquire a lock first, since these functions modify an array belonging to the engine.  I'm not suggesting that the functions themselves should block.  I am just confirming that the burden is on the application to synchronize those module-related activities.

// Create a new script module
asAcquireExclusiveLock();
asIScriptModule *mod = engine->GetModule("module", asGM_ALWAYS_CREATE);
asReleaseExclusiveLock();

// Load and add the script sections to the module
string script;
LoadScriptFile("script.as", script);
mod->AddScriptSection("script.as", script.c_str());

// Build the module
int r = mod->Build();

// ... Do something with the module

asAcquireExclusiveLock();
mod->Discard();
asReleaseExclusiveLock();

C++ Compiler Warning

28 October 2014 - 08:00 AM

This is not a big deal, but I build my projects with Microsoft's VC++ compiler, and I set the warning level to 4.  When I build AngelScript targeting the x64 platform I get the following compiler warning.

 

>source\as_builder.cpp(240): warning C4267: 'initializing' : conversion from 'size_t' to 'AngelScript::asUINT', possible loss of data

 

I would recommend an explicit cast here so that the warning does not appear.

 

asUINT numTempl = (asUINT)engine->templateInstanceTypes.GetLength();

 


Implicit Convert Math Bug

09 October 2014 - 12:08 PM

I think there's a bug somewhere when compiling math operators and using implicit conversion functions.  The following test fails.

int x = 1;
class A
{
    int val;
    A(int x)
    {
        val = x;
    }
    int opImplConv()
    {
        return val;
    }
}

A myA(5);

void main()
{
    assert(myA + (x + 1) == myA + x + 1);
}

The error seems to be that after the CALLINTF instruction for A::opImplConv there is no following CpyRtoV4.  The error is in the bytecode generated on the left side of the comparison.

 

Also, if the global declaration of "x" is removed and a local declaration of "x" is added to the main function the bug is gone.

 


ActiveContext for Context and Module Cleanup

30 September 2014 - 02:06 PM

I have some script objects which call asGetActiveContext in their constructors, using information from the custom user data.  Since the asCModule::ResetGlobalVars function now takes a context pointer, those objects function properly.

 

I also need to have access to the context in the destruction of those objects, but there is no "active" context when a module is being discarded or when a context is being unprepared.  Could the asCModule::Discard function be changed to take a context, and could the asCContext::Unprepare function be changed to set itself to the active context before releasing objects?

 

I haven't provided a patch myself, because I'm not sure if those changes would clash with the design or if there is some subtle issue with setting a context to the active one as it is unprepared.

 

Thanks


Ambiguous Enum Comparison

11 September 2014 - 01:15 PM

The following code will produce an error, even though the ambiguity could be resolved.

enum MyEnum1
{
    cYes,
    cNo
}

enum MyEnum2
{
    cNo,
    cYes
}

bool main()
{
    MyEnum1 e = cNo;
    return e == cYes;
}

I have attached a patch that resolves the ambiguity.

 


PARTNERS