On 17 May 2018 at 13:25, Shachar Shemesh via Digitalmars-d <[email protected]> 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++!
