www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Scope of enum

reply DLearner <bmqazwsx123 gmail.com> writes:
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
Jul 11
parent reply jfondren <julian.fondren gmail.com> writes:
On Sunday, 11 July 2021 at 10:58:58 UTC, DLearner wrote:
 Is there a way of forcing DMD to extend the scope of `MemSiz` 
 to include `k_mod`?

 Best regards
``` $ 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] ```
Jul 11
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Sunday, 11 July 2021 at 12:01:27 UTC, jfondren wrote:
 On Sunday, 11 July 2021 at 10:58:58 UTC, DLearner wrote:
 Is there a way of forcing DMD to extend the scope of `MemSiz` 
 to include `k_mod`?

 Best regards
``` $ 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`` ```
Jul 11
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 11 July 2021 at 12:37:20 UTC, DLearner wrote:
 C:\Users\SoftDev\Documents\BDM\D\Examples\CTFE\T2>type k_mod.d
 // k_mod.d


 ubyte[MemSiz]  MemPool;
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.
Jul 11
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Sunday, 11 July 2021 at 12:47:48 UTC, Adam D Ruppe wrote:
 On Sunday, 11 July 2021 at 12:37:20 UTC, DLearner wrote:
 C:\Users\SoftDev\Documents\BDM\D\Examples\CTFE\T2>type k_mod.d
 // k_mod.d


 ubyte[MemSiz]  MemPool;
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.
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?
Jul 11
parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 11 July 2021 at 13:21:35 UTC, DLearner wrote:
 Is there a 'D' way of avoiding the issue?
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
Jul 11