[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()

[Zachary Turner via lldb-commits]

On Tue, Nov 28, 2017 at 10:24 AM Zachary Turner <zturner at google.com> wrote:

> On Tue, Nov 28, 2017 at 10:18 AM Greg Clayton <clayborg at gmail.com> wrote:
>
>> On Nov 27, 2017, at 10:11 PM, Zachary Turner <zturner at google.com> wrote:
>>
>> As an aside, I don't really like this class.  For example, You can
>> currently assign a UUID[16] to a UUID[20].  That doesn't make a lot of
>> sense to me.
>>
>>
>> What about an invalid UUID[0] being assigned with a valid UUID[16] or
>> UUID[20]? Why doesn't this make sense? I don't follow.
>>
>
> Nothing is invalid, I just think it's better and expresses the intent more
> clearly if you can only assign between UUIDs of the same size.  For
> example, If the UUID class were templated on size, then there would not
> even be such thing as a UUID[0] or a "universally invalid UUID".  There
> would be an "invalid 16-byte UUID" and an "invalid 20-byte UUID", and those
> would be different things.
>
>
>>
>>
>> As a future cleanup, I think this class should probably be a template
>> such as UUID<N>, and then internally it can store a std::array<uint8_t,
>> N>.  And we can static_assert that N is of a known size if we desire.
>>
>>
>> UUID values are objects contained as members inside of other objects.
>> They all default to start with no preconceived notion of what the UUID
>> should be. IMHO the UUID class is just fine and needs to be able to
>> represent any UUID, from empty uninitialized ones, and be able to be
>> assigned and changed at will.
>>
>>
> Is there ever a use case for changing the number of bytes in a UUID?  If
> you're working with 16-byte UUIDs, does it ever actually happen that now
> you have a 20-byte UUID?  Can you imagine a use case currently where an
> N-byte UUID is being compared against an M-byte UUID in a real-world
> scenario?  If the answer is no, then it may as well be enforced by the
> compiler.
>

Also, if the data is just a `std::array`, and that size can never change,
then memcmps and finds are replaced with equality operators, which is a win
IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171128/9e8062fa/attachment.html>