search

boostorg / winapi

Windows API declarations without <windows.h>, for internal Boost use.
62 stars 58 forks source link

Normalize the interlocked.hpp header and move it into the right place #55

Closed jeking3 closed 6 years ago

jeking3 commented 6 years ago

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).

Lastique commented 6 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.

jeking3 commented 6 years ago

Where should it go? :)

Lastique commented 6 years ago

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.