Please see the two code snippets below:

// test01.d

enum MemSiz  = 240;

void main() {

   import k_mod;
}

and

// k_mod.d

ubyte[MemSiz]  MemPool;

A number of tests need to be run on code in k_mod,
with different sizes of the static array MemPool in each test.
So each test has the enum MemSiz, but set to different values.

However, DMD does not recognise the enum MemSiz within k_mod,
failing with 'undefined identifier'.

Is there a way of forcing DMD to extend the scope of MemSiz to include k_mod?

Best regards

On Sunday, 11 July 2021 at 10:58:58 UTC, DLearner wrote:

$ cat k_mod.d
import test01;

ubyte[MemSiz] MemPool;

$ cat test01.d
enum MemSiz = 240;

void main() {
    import std.stdio, k_mod;
    writeln(typeid(MemPool));
}

$ dmd test01.d k_mod.d
$ ./test01
ubyte[240]

On Sunday, 11 July 2021 at 12:01:27 UTC, jfondren wrote:

$ cat k_mod.d
import test01;

ubyte[MemSiz] MemPool;

$ cat test01.d
enum MemSiz = 240;

void main() {
    import std.stdio, k_mod;
    writeln(typeid(MemPool));
}

$ dmd test01.d k_mod.d
$ ./test01
ubyte[240]

Doesn't seem to work for me (Windows):

C:\Users\SoftDev\Documents\BDM\D\Examples\CTFE\T2>type test01.d
//  test01.d

enum MemSiz  = 240;

void main() {

   import k_mod;
}


C:\Users\SoftDev\Documents\BDM\D\Examples\CTFE\T2>type k_mod.d
// k_mod.d


ubyte[MemSiz]  MemPool;


C:\Users\SoftDev\Documents\BDM\D\Examples\CTFE\T2>dmd -i test01.d k_mod.d
k_mod.d(4): Error: undefined identifier `MemSiz``

On Sunday, 11 July 2021 at 12:37:20 UTC, DLearner wrote:

You didn't import the other module here.

D's imports aren't like C's includes. Each module is independent and can only see what it itself imports.

A module has no idea who is importing it. It only knows what it imports inside itself.

On Sunday, 11 July 2021 at 12:47:48 UTC, Adam D Ruppe wrote:

Adding the second import worked - thank you.

But there is a point of principle:
To me, doesn't really matter about what goes in test01.d, just test harness.

But adding import test01.d to k_mod.d looks like 'mixing' the real code in k_mod.d with other code that is just for the support of the test harness.
And that support would have to be changed for each test.
Surely we want the target code, if possible, to be unchanged from test to test?

Is there a 'D' way of avoiding the issue?

On Sunday, 11 July 2021 at 13:21:35 UTC, DLearner wrote:

Pass the size as a parameter to the thing instead of trying to combine things. like

mixin template Thing(size_t size) {
ubyte[size] pool;
}

and where you want it like

mixin Thing!(100);

and somewher eelse

mixin Thing!(500);

and they're separate variables with different sizes that you can use.

idk what your thing needs in context though