On Monday, August 29, 2011 13:35 Benjamin Thaut wrote: > I hoped for a little bit more feedback about the article itself. > Especially about the move constructor I suggested. Does anyone see a > need for this, or is it just me?
Honestly, I find the fact that you're writing code which relies on the address of a variable on the stack a bit scary. Normally, that is a _bad_ idea. Now, you're obviously doing something quite abnormal, so it may be a good idea in your case, but you're definitely not doing something which your average programmer is going to need to do. And the fact that structs can be moved by having their bits copied around is a definite boon for efficiency. Adding move constructors would definitely complicate things. If there were enough use cases for them, then they may be worth adding, but at this point, the compiler definitely relies on the fact that it can move a struct without affecting it, so any code which relies on a struct _not_ moving is likely to be broken. The ramifications of adding move constructors are likely far from trivial. Personally, I'd argue that it doesn't make any more sense to expect that a struct's location have _anything_ to do with its value, and that if you want to rely on its location, then you need to put it in a location that you can rely on. If anything, I'd argue that your structs should just have a variable identifying them if you want to have them be uniquely identifiable, but I don't really understand what you're doing. Certainly, for the common case, adding move constructors is a needless complication, and I'd _very_ leery of the ramifications of the compiler not being able to rely on a move having the bits stay absolutely identical (and a move constructor would make it possible for the struct's state to change completely instead of really being a move). It's not necessarily completely unreasonable, but you appear to have found what I would expect to be a _very_ abnormal use-case. - Jonathan M Davis