<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 12:32 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2c5" class="a3s" style="overflow:hidden">Hi Zachary,<br>
<br>
In LLVM platform-specific code goes in the implementation files (.inc) and never in the portable headers. Certainly for a high-level class like Mutex I wouldn't expect to see platform-specific conditionals exposed.<br>

<br>
A couple of exceptions have slipped in like Support/FileSystem.h and Support/Process.h with ifdef WIN32 but those are meant to get fixed at some point.</div></blockquote></div><br></div><div class="gmail_extra">While you may be describing the current situation, I don't think that this is really a strong rule than many LLVM developers feel constrained by, and I wouldn't want it to be.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think the important rule is subtly but importantly different: the header files must, ultimately, be portable. Where possible, it is useful to isolate platform specific code away from header files, but it is not always possible or desirable. Either way, the header file needs to carefully manage any platform specifics involved to ensure it works correctly and reliably across platforms.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">One example of this (but not necessarily a *good* example -- I would use a different technique) is our DataTypes.h which is generated at configure/cmake time.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think it is entirely possible that the correct thing to do for some parts of Support is to include windows.h with appropriate control of macros and behind appropriate guards. I say it is "possible" because I don't know very much about the *specific* case of windows.h and its problems. Perhaps there are specific problems with it that make it intractable to use in this way even on Windows. But the general concept seems fine when useful. Similarly, if we wanted to include a Mac OS X header file to access a synchronization or other primitive provided by the OS, it would seem reasonable to include that header, again provided sufficient care and guards are used to make sure the header, as a whole, remains a reliable header for other projects to use on each platform.</div>
</div>