Hi, Thanks first for your detailed reply!
On 03/07/2011 07:21 PM, Jonathan M Davis wrote:
Well, Tuple _is_ a struct, so if it's failing with Tuple, it's not going to work with just any struct (though apparently it works just fine with the struct that you wrote). Regardless, it definitely sounds like a bug in sort (or something that sort uses). You should probably open a bug for it: http://d.puremagic.com/issues/ Though honestly, I don't know why you'd want to use a tuple in this case. I tend to think that if you're going to name the fields, you might as well declare a struct, but whatever.
I started using Tuples only but I used the naming feature to exchange the Tuple and struct implementations easily. Anyway this is no production code, just test code to learn D :) Anyway I'll open a bug for it. Thanks for the link!
Oh, on a side note, your opCmp is wrong on two counts. First off, its signature should be int opCmp(ref const TestT rhs) const I don't think that sort even calls you opCmp, because its signature is wrong (arguably, the compiler is currently overly picky about the signature for opEquals and opCmp, but they _must_ be exact). So, the default comparison is being used, not your opCmp.
I tried both signatures of opCmp but the result seemed the same (both sequences of structs sorted correctly). So I wonder what is the default comparison of a user defined struct type? Not implementing an opCmp function lead to a compiler error..
The second problem (which you may know about but not have cared) is that using subtraction like that in opCmp is going to fail if the numbers are large enough that you get overflow. For a completely correct comparison function which uses integral types, you need to actually do proper comparisons, not subtract them. If you _know_ that your numbers are small enough though, it doesn't actually matter, since you'll never get an overflow.
I actually didn't care about that problem but I _will_ do that in future. Regards, André
