On Tue, Nov 28, 2017 at 10:24 AM Zachary Turner <ztur...@google.com> wrote:
> On Tue, Nov 28, 2017 at 10:18 AM Greg Clayton <clayb...@gmail.com> wrote: > >> On Nov 27, 2017, at 10:11 PM, Zachary Turner <ztur...@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.
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits