strtr: >Might this be worth an explicit mention on digitalmars?< Currently the documentation has some semantic holes that must be filled :-)
> Suppose I'd still would like to use void optimizations, how do you clear the > holes manually? If you need to fill the holes manually, then probably it's better to let the compiler clear the whole struct automatically at the beginning. If you really want to clear the struct instance manually, I can see few ways to do it: - don't leave holes in the struct, use an align(1) - use a memset(&somestruct, o, sizeof(typeof(somestruct))); This is preferred because it's safe, short, and fast. - Add strategically placed dummy items inside the struct, in the same position and size of the holes it has, and then assign them to zero normally. Holes do change in size for different operating systems (think about the type real, that has a different length across different operating systems, 10, 12 and 16 bytes), so this seems a bit too much complex way to solve the problem. > Not that I'm touching void any more, just interested :) Sometimes void structs are useful, in performance critical spots of the program. But I suggest you to avoid it when possible. You have to be careful, because they can contain spurious pointers, that the conservative GC will use to keep objects alive. This happens especially if the struct contains pointers in the first place. >I suspect this isn't the case for void initialization; if my struct has some >alignment hole I better not void initialize it if ever I want to compare it >with somthing.< >And unless you will never compare the struct, as the garbage bits will also be >compared.< I don't know. A well implemented opEquals and opCmp among structs has to ignore the contents of the holes. I have to do experiments *and* to go look at Phobos source code. In any case the D documentation must explain 100% about how such things work, the compiler writer must not be free to choose here. Bye, bearophile
