Getting the names of all the top-level functions in module

Stefan Koch uplink.coder at googlemail.com
Tue Sep 21 23:27:49 UTC 2021


On Tuesday, 21 September 2021 at 22:53:26 UTC, Stefan Koch wrote:
> On Tuesday, 21 September 2021 at 17:15:23 UTC, Stefan Koch 
> wrote:
>> On Tuesday, 21 September 2021 at 15:18:01 UTC, Stefan Koch 
>> wrote:
>>> On Tuesday, 21 September 2021 at 15:07:35 UTC, Adam D Ruppe 
>>> wrote:
>>>> Here's one with param names:
>>>>
>>>> ----
>>>>
>>
>> I've done a little benchmark the core.reflect version vs the 
>> template version.
>>
> Scratch that.
> It turns out I should have tested the output.
>
>
> The simple truth of this is that the CTFE concatenation is the 
> weak link here.
>

So if ctfe is the limiting factor how does the graph look when 
CTFE is taken out of the picture.
![](https://i.ibb.co/bJsshPZ/without-ctfe.png)

That's how.
core.reflect looks linear
while the template shows signs of becoming superlinear.
However I cannot test it on bigger N because there is a 
restriction to how many synthetic symbol-names the compiler can 
create  ...

```d
                     // Perturb the name mangling so that the 
symbols can co-exist
                     // instead of colliding
                     s.localNum = 
cast(ushort)(originalSymbol.localNum + 1);
                     assert(s.localNum);         // 65535 should 
be enough for anyone
```

ah well :-)
It should be noted that core.reflect can be used with much higher 
N because it doesn't create symbols in that way.



More information about the Digitalmars-d mailing list