std.uuid: Update 4

[Alex Rønne Petersen]

On 17-06-2012 10:22, Johannes Pfau wrote:
> Am Sun, 17 Jun 2012 12:15:00 +0400
> schrieb Dmitry Olshansky<dmitry.olsh at gmail.com>:
>
>> On 17.06.2012 12:04, Johannes Pfau wrote:
>>> Am Sat, 16 Jun 2012 21:11:51 +0400
>>> schrieb Dmitry Olshansky<dmitry.olsh at gmail.com>:
>>>>
>>>> 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
alex at lycus.org
http://lycus.org