<div dir="ltr">Another thing to note is that I'm about done with the C++ layout code which I think I'm just going to add to this patch, which will about double the code size and may alter this discussion some.  The overall approach is to build something that is not dependent on the current implementation, make sure it works, switch to it and then delete/clean all the existing code to handle MS ABI in another patch.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 28, 2013 at 2:50 PM, Warren Hunt <span dir="ltr"><<a href="mailto:whunt@google.com" target="_blank">whunt@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">That is reasonable, we can certainly fuse them into a single file and that will make sharing some C-layout code easier.  I can do that.  I personally find (more) smaller files easier to navigate and tend to break things apart.  Of course that causes either duplication of code or re-factoring into headers.<span class="HOEnZb"><font color="#888888"><div>

<br></div><div>-Warren</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 4:03 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Jun 27, 2013, at 1:16 PM, Warren Hunt <<a href="mailto:whunt@google.com" target="_blank">whunt@google.com</a>> wrote:<br>


> The C differences are, to my knowledge, only in bit-fields.  One of the reasons that this C code has been broken into a separate file is because I'm implementing C++ as an extension to the C code and it's going in the same file.  The current state is that I should have a full MS-32-ABI C++ layout patch up late this week.  I presented a C patch first so that we could start the code review process rather than some belief that compiling C code in a MS-compatible way was particularly important.  The C++ patch presently assumes the current structure where there's one file with C and C++ semantics for MS.  It's been helpful for me to have all of the MS stuff isolated so I can turn it off/on easily and gives me more confidence I'm not breaking anything in the interim (it will also certainly make merging with Eli's patch trivial).  I'm happy to have a discussion about the ultimate organization of all of the layout code.  The MS C++ layout algorithm is *completely different* than the Itanium one so I would suggest keeping them separate.  Breaking C out from C++ can certainly be done and may provide some benefit, presently my MicrosoftCXXRecordLayoutBuilder inherits from the MicrosoftRecordLayoutBuilder.<br>


<br>
</div>Sorry, I may not have been clear.  I'm not suggesting that you should put the C code in the same file only to break it all out again when you do C++, or to try to factor the C++ implementations to reuse things.  I'm suggesting that, unless the correct Microsoft code is substantially larger than the not-fully-correct code we've already got in RecordLayoutBuilder.cpp, there may be advantages to just leaving all the code in one file.  For example, it would make it easier to share what common algorithms do exist between them (such as, presumably, the basic C field layout algorithm, which will be shared among all the implementations, but which is not totally trivial due to all the random things that adjust field alignment) without needing to expose any of that.<br>


<span><font color="#888888"><br>
John.</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>