I think something along these lines should do:
fn bitwise_compare<T>(a: &T, b: &T) -> bool {
use std::{ptr,sys,cast,uint};
let size = sys::size_of::<T>();
unsafe {
let a: &u8 = cast::transmute(a);
let b: &u8 = cast::transmute(b);
for uint::range(0,size) |n| {
if *ptr::offset(a,n) != *ptr::offset(b,n){
return false
}
}
}
true
}
Note that it won't work for strings and vectors. It could be slightly more
efficient by comparing in larger chunks than u8, but LLVM will probably
figure that out.
On Fri, Jul 19, 2013 at 3:06 AM, David Piepgrass <qwertie...@gmail.com>wrote:
>
> > I think at the least we should offer a #[deriving(Basics)] for use on
>> public
>> > types so that people aren't forced to memorize "Eq Ord TotalOrd TotalEq
>> > IterBytes Clone" (unless we can find a silly SFINAE-esque acronym...
>> > http://www.wordsmith.org/anagram/anagram.cgi?anagram=eottic ).
>>
>> Plenty of types can't actually be ordered, and in *many* cases not all
>> fields should be considered for equality/ordering and they may or may
>> not be listed in the order the comparison should try.
>>
>> The only two that rarely require any extra consideration are
>> `Clone`/`DeepClone`, since they should be on almost every type without
>> a destructor.
>>
>>
> I just had a random thought.
>
> I once implemented a data structure for .NET called a VList (
> http://www.codeproject.com/Articles/26171/VList-data-structures-in-C)
> which provided a "SmartSelect" pseudo-LINQ method. If you had a list of
> numbers, you could ensure they are all positive like this:
>
> list.SmartSelect(x => Math.Max(x, 1))
>
> The reason it's called SmartSelect is that it returns a changed list only
> if the select operation *changes* any of the values (and even then it may
> still be able to re-use the tail of the list). The tricky part is detecting
> when there has been any changes. Ideally I would have liked to simply do a
> bitwise equality test because it would be very fast and requires no special
> support from the data type, but .NET doesn't have a bitwise equality test.
> So I ended up having to use a test that always requires dynamic method
> invocation, which I have heard is fantastically slow in the general case of
> structs that don't implement IEquatable<T>.
>
> I wonder if Rust could, in the general case, allow my bitwise equality
> test. I realize that bitwise equality isn't "real" equality, but in this
> case it's good enough. For instance if the selector changes -0.0 to +0.0,
> which is value-equal but bitwise-different, the effect is fairly
> harmless--a partially new list is allocated instead of re-using the old
> list.
>
> Of course, if the list contains references (~T, @T), the bitwise test
> should compare the references themselves, without dereferencing.
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
