The review of std.hash package

Jonathan M Davis jmdavisProg at gmx.com
Wed Aug 8 13:44:03 PDT 2012


On Wednesday, August 08, 2012 20:55:19 Johannes Pfau wrote:
> Am Wed, 08 Aug 2012 14:36:32 -0400
> 
> schrieb "Jonathan M Davis" <jmdavisProg at gmx.com>:
> > What's wrong with the *endianToNative and nativeTo*Endian functions?
> > They work just fine as far as I know. swapEndian works too if you
> > want it to use that, but there should be nothing wrong with the
> > endian-specific ones.
> > 
> > - Jonathan M Davis
> 
> in CTFE?
> http://dpaste.dzfl.pl/0503b8af
> 
> According to Don reinterpret casts (even if done through unions) won't
> be supported in CTFE. So you can't convert from uint-->ubyte[4]

No. It wouldn't work in CTFE, because it uses a union. But what it's trying to 
doesn't really make sense in CTFE in most cases anyway, because the endianness 
of the target machine may not be the same endianness as the machine doing the 
compilation. Any computations which cared about endianness must be in a state 
where they don't care about endianness anymore once CTFE has completed, or 
you're going to have bugs.

Though if the issue is std.hash being CTFEable, I don't know why anyone would 
even care. It's cool if it's CTFEable, but the sorts of things that you hash 
pretty much always require user or file input of some kind (which you can't do 
with CTFE). You'd have to have a use case where something within the program 
itself needed to be hashed for some reason for it to matter whether std.hash 
was CTFEable or not, and it wouldn't surprise me at all if it were typical in 
hash functions to do stuff that isn't CTFEable anyway.

- Jonathan M Davis


More information about the Digitalmars-d mailing list