On Jun 27, 2013, at 1:16 PM, Warren Hunt <[email protected]> wrote: > 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 t! he 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.
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. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
