Sign in to follow this  

stringConstants larger than 65536

Recommended Posts

Dear Andreas:

 

I need a very large string table to generate some times.

usually I write some code like that:

void do_job(string[]@ ar)
{
 ......................
}

void main()
{
  string[] samples =
  {
    #include "strings.txt"
  }

  do_job(samples);
}

strings.txt is a very large file like (usually 100000 lines)

".Database/001/IDX/00.idx",
".Database/001/IDX/01.idx",
".Database/002/IDX/02.idx",

.......

 

 

 

But I saw the following codes in as_scriptengine.cpp

int asCScriptEngine::AddConstantString(const char *str, size_t len)

{

   // The VM currently doesn't handle string ids larger than 65535

   asASSERT(stringConstants.GetLength() <= 65536);

}

How should I do to exceed 65536 string constants ?

Share this post


Link to post
Share on other sites

Instead of including the strings as literal constants in the code can you load them dynamically at run-time? That will allow you to use as many strings as you want without any changes in the library.

 

 

To make the VM support more than 65536 literal string constants it will be necessary to make a few different changes in the compiler, VM, and the serialization of bytecode. Any JIT compiler (e.g. Blind Mind's) will also have to be modified to support the changes done to the bytecode instructions.

 

I have an item on my to-do list already to add support for more string literals in the code, but I haven't had the time to work on it yet.

Share this post


Link to post
Share on other sites

Dear Andreas:

Thanks for your reply.

I realize that loading string at run-time could do the task.

But my team members prefer the straightforward way.

I glanced round your codes, the key point is asBC_STR.

I will try to do a little changes.

 

Thanks for your angelscript , we have 20~30 members writing the script codes.

Share this post


Link to post
Share on other sites

Wow, that is a quite large team. :)

 

Yes, asBC_STR is the cause for the restriction at the moment. If you don't currently care about JIT compilation and serializing compiled bytecode, you ought to be able to change this instruction to be of the type asBCTYPE_DW_ARG instead of asBCTYPE_W_ARG quite easily.

 

In my future enhancement I'm studying a bit more extensive change to solve a few different problems 1) current limit of the number of supported constants 2) avoid duplicate memory with the script engine storing one copy of the constant and the application keeping its own string pool 3) improve performance by avoiding run-time allocation of string constants where possible.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this