On 17 May 2018 at 13:25, Shachar Shemesh via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On 17/05/18 22:29, Manu wrote:
>> This is great!
>> I've wanted this on numerous occasions when interacting with C++ code.
>> This will make interaction more complete.
>> Within self-contained D code, I have avoided self-pointers by using
>> self-offsets instead in the past (a bit hack-ey). But this nicely
>> tidies up one more little rough-edge in the language.
>> :+1:
> Following Andrei's advice, I've actually started writing a couple of
> examples to illustrate why this is needed.
> The first was this:
> struct S {
>   static int global;
>   int local;
>   Something selector; // Decides whether we want local or global.
> }
> Let's further assume that we have an array of S instances with random
> uniform distribution between local and global.
> Obviously, Something can be an enum or a boolean. If it is, however, then we
> have to perform a condition to select the correct value. The problem with
> conditionals is that if the CPU misses a guess about what they are (and in
> our case, the CPU is going to miss about 50% of the time), they are
> extremely expensive to evaluate.
> Performance wise, a much saner approach is:
> alias Something = int*;
> Of course, this means our struct now has a self referencing pointer.
> What I'm getting at is that even if there are alternatives to structs
> pointing at themselves, they may not be performance wise comparable to
> pointers.
> Of course, the second example was a struct that has no internal pointers,
> but rather maintains global pointers pointing to it. This problem is quite a
> bit harder to solve.
> Shachar

Oh yeah, I totally recognise that there are instances where a local
offset is not a solution, I was just saying how I've managed to
avoided dealing with this issue before, and not that I loved doing so
that way ;)
This would be a very welcome fix, particularly in code where I
interact with C++!

Reply via email to