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 ?

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.

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.

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.

This restriction has now been removed in the latest WIP version. 

https://www.gamedev.net/forums/topic/693565-angelscript-changes-to-how-string-literals-are-handled/