On 17-06-2012 10:22, Johannes Pfau wrote:
Am Sun, 17 Jun 2012 12:15:00 +0400
schrieb Dmitry Olshansky<[email protected]>:
On 17.06.2012 12:04, Johannes Pfau wrote:
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky<[email protected]>:
Ah and another way to go about it is:
union {
ubyte[16] uuid;
size_t[16/size_t.sizeof] by_word;
}
Isn't that an optimization which should really be done by the
compiler? It already knows that it's supposed to compare two
ubyte[16]...
It knows that you compare two ubyte[16] that it.
It easily might miss the fact that one of them is always 0 in all 16
cells.
Also how could the union solution be used without having to copy the
data?
There is no copy it union, aka overlapped storage. In other words as
these 16 bytes represented as (on 32bit) 4 size_t. They share memory
location. It doesn't play nice with CTFE though, as it thinks unions
to be plain struct last time I checked.
Yes, I thought about using the union nested in the empty function, so a
copy would have been needed:
bool empty()
{
union
{
ubyte[16] uuid;
....
}
uuid = data; //copy
}
I didn't know that it's possible to make members of a union private
though, so I could use this in the UUID struct:
union
{
ubyte[16] data;
private size_t[16/size_t.sizeof] by_word;
}
which indeed wouldn't require copying. However, with this code added
std.uuid fails some unrelated ctfe UUID comparison unittests...
I wouldn't expect unions to be CTFE-safe at all. They allow
reinterpreting anything as anything, which could screw everything up in
a managed environment like the CTFE interpreter.
Anyway, isn't this optimizing something that really doesn't need
optimization? I'd be very surprised if this shows up in any profiling
results at all.
--
Alex Rønne Petersen
[email protected]
http://lycus.org
