<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 10:11 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.</div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>Greg</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Nov 27, 2017 at 9:38 PM Davide Italiano via Phabricator <<a href="mailto:reviews@reviews.llvm.org" class="">reviews@reviews.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">davide added a comment.<br class="">
<br class="">
Yes, what Zachary said. Thanks for the cleanup. There's a decent amount of code in lldb that can be written in a very compact way but it's manually unrolled. I think in this case the code produced should be equivalent (and if not, I'd be curious to see the codegen).<br class="">
More generally, whenever a function is not in a hot loop, we might consider preferring readability over performances anyway.<br class="">
<br class="">
<br class="">
<a href="https://reviews.llvm.org/D40537" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D40537</a><br class="">
<br class="">
<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>