On Thursday, September 19, 2013 18:47:12 Daniel Davidson wrote: > Multi-part question: > > 1) Why does the last line fail? If cast to immutable how is it > different than z? I know it is related to the ref. I'm using ref > because I think it is likely more efficient - so assume the > char[16] were really char[1024].
As Namespace pointed out, ref (including const ref) does not accept rvalues - only lvalues. > 2) If I got rid of the ref, how many copies of the data would be > made? And without looking at assembly what is a good way to > answer this question? I've tried to add this(this) to other Stuff > type structures to print when they are being called, but that > does not work because no logic can be in the default constructor. That would depend on what functions are being called and could change if the code is refactored. The compiler will do moves instead of copies whenever it can, so the situation is far better than with C++ (particularly pre-C++11), but how many copies will actually be needed depends on what the functions are doing and how many functions get called. Writing a postblit constructor would be the only way that I know to track it, though I'm not sure why the lack of default construction would be a problem, unless you're trying to name all of your objects and print out exactly how many each individual one is copied. But if you want to do that, then create a constructor that you pass the name, and don't use a default-initialized value. > 3) Also, is storing immutable(STUFF) in a struct in the general > case (as opposed to just this one) useful or silly? As soon as you have a const or immutable member in a struct, you can't ever assign anything to it, even if all of its other members are mutable (you could assign the individual, mutable members but not the whole struct). That means stuff like if the struct is ever default-initialized, you can't even give it another value, which tends to mean that you can't use such a struct in places like arrays. All in all, I think that it's pretty much always a bad idea to have a struct with const or immutable members. It's just begging for problems. Tail-const or tail-immutable is fine, because the members themselves aren't const or immutable (just what they refer to), but having them be directly const or immutable is a bad idea IMHO. - Jonathan M Davis
