Too many local constants. Use shorter procedures error

Question

I am using Delphi 6, I am preparing a list which will have some variable string name and its pointer reference. Code is some what like,

var
  VarList: TstringList;

procedure AddNameList(aName :string; aRef: TObject);
begin
  VarList.AddObject(aName, aRef);
end;

Above method AddNameList is called in Unit1.pas, I have roughly 5 to 6 thousand entries and this can increase.

Now unit1 contains

AddNameList('MyVar1', MyVar1);
AddNameList('MyVar2', MyVar2);
AddNameList('MyVar3', MyVar3);
...
..
..
AddNameList('MyVar5000', MyVar5000);

Compiler is giving me the error

Too many local constants. Use shorter procedures

I tried to divide this in two procedures then also it did not work. I referred posts available and similar to this error, which suggest to use constant arrays. But in that case I need to maintain two constant array and maintaining this two array will be difficult since the number of constant is huge. Is there any other way to resolve this issue.

Answer 1

From my experimentation, Delphi 6 has an upper limit of 3297 distinct string literals. This limit is a per unit limit. So one solution is to find a way to split your code into separate units. It's not very elegant, but then this code doesn't seem very elegant to me and frankly I'm not sure that using multiple units really makes things that much worse.

Update

It turns out my experimentation was poorly conducted. The limit is actually per function rather than per unit. So splitting the code into multiple functions will suffice.

---

For what it is worth, modern versions of Delphi have a much larger limit (if indeed there is a limit), on the number of string literals per unit. In XE7 I made it to 160,000 distinct literals without the compiler objecting before I gave up.

Presumably your code is automatically generated? I wonder if it is possible for you to replace this giant list of calls to AddNameList with a loop that calls AddNameList. The data to be passed to AddNameList would have to be read from somewhere, perhaps a linked resource. Or is it even possible to generate all these calls programmatically.

Without knowing the precise details of how you find yourself with code using distinct calls rather than iteration, it's hard, in my view, to offer much more detailed advice.