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