Closed jeking3 closed 7 years ago
interlocked.hpp was historically not part of Boost.WinAPI and in fact does not define WinAPI functions. I'm not convinced it should be moved inside boost/detail/winapi.
Where should it go? :)
It's fine where it is, IMHO. Another place could be Boost.Atomic, but it's not perfect either because Boost.Atomic is not about providing Windows-specific macros. Also, it would change the dependency graph and would have to be discussed on the ML. Basically, Boost.WinAPI is the place that makes most sense currently and doesn't impose many more dependencies on its users.
This header appears to have been one of the earliest in the suite. It does not follow the flow of the rest of the winapi headers and should be refactored to fit in, and also moved into the right place. To maintain backwards compatibility, a deprecation warning header can be left in its place for one release (and another issue should then be filed to remove it in the following release).