The scripthelper config helper functions are not working correctly.

WriteConfigToStream does not write the namespace of function parameters.

The cause is asIScriptFunction::GetDeclaration not considering the namespace.

ConfigEngineFromStream does not handle the empty namespace correctly, so if the namespace was changed and returned to empty, the parser will fail.

This code can parse namespaces correctly:

auto uiEnd = config.find( '\n', pos );

string ns = config.substr( pos, uiEnd - pos );

pos += ( uiEnd - pos );

uiEnd = ns.find_first_not_of( " \t" );

if( uiEnd != string::npos )
	ns = ns.substr( uiEnd, ns.length() - uiEnd );
else
	ns = "";

Thanks. I'll look into it.

Thanks.

Also, object type flags don't include all flags because the flags are bitwise ANDed with 0xFF, which causes flags like asOBJ_NOCOUNT to be excluded. This causes script compilation to fail.

I have discovered another problem: the default configuration write and read order causes problems with template types.

For example, if you use the default array class, and use arrays in your API, and the functions using them are listed before the array constructors, script compilation will fail because the compiler considers the array specialization to be uninstantiable.

This is because the array factory list is empty, which happens because the specialization is copied from the registered template type before factory methods are registered.

I solved this issue by making WriteConfigToStream first output the array type, but a better solution would be one where template types are fully registered before all other types.

This can still cause issues if one template type uses another template type as a specialization. A way to detect dependencies would be needed, which (if i'm not mistaken) involves iterating over the parameters of every method registered to template types.

Only the constructors/factories need to be registered first, so that simplifies things a bit.

Thanks. I'll look into all of these problems. Let me know if you find any other.

The first 2 problems have been fixed in revision 2106.

The analysis of the last problem continues.

Regards,

Andreas

I upgraded our codebase to the latest version on SVN; parameters now have their namespace set correctly, but the namespace token itself still isn't being parsed correctly.

Empty namespaces cause the parser to consider the next token to be the namespace identifier, which could be something like 'enum'.

Can you show me the part of the config that you're seeing the problem with? (I want to make sure I have the correct understanding of what you're saying)

This is a snippet from the config generated from our API:

namespace Reflection
enum ArgumentType
enumval ArgumentType AT_NONE 1
enumval ArgumentType AT_VOID 2
enumval ArgumentType AT_PRIMITIVE 4
enumval ArgumentType AT_OBJECT 24
enumval ArgumentType AT_ENUM 32
namespace 
enum HookReturnCode

When the config parser reaches the second namespace token, it considers 'enum' to be the name of the namespace.

Thanks. Now it is clear what the problem you were referring to is. I'll have it fixed.