On Mon, 13 Jan 2025 at 14:01, Peter Dimov <pdimov@gmail.com> wrote:
Ruben Perez wrote:
In the general case (when a header also defines macros), the public header will contain both
import boost.mp11;
and the part that defines the macros, which in Mp11's case is
#include <boost/mp11/version.hpp>
User code wouldn't need to know that in addition to the import, it also needs to include a separate macro header.
This assumes that macros are "standalone" and don't require including any stdlib headers. This is the case for mp11/version.hpp and lightweight test, but is not for Boost.Config or Boost.Charconv headers, for instance. These may require including <cstddef> or <cstdint> for macros, which need to happen before any import std. Wouldn't this cause trouble with your scheme?
Possibly, yes. If we want to keep the public headers usable in a module unit, we can't include <cstddef> there because it will introduce declarations.
Although whether we need to keep the headers usable in a module unit is up for debate.
Fixing this properly can only be done on the stdlib/implementation side.
I think this applies for non module units, too. I've just tested that, under MSVC, the following errors: // File: main.cpp import std; #include <cstddef> int main() {} This does not seem to happen with all the headers, though. * version, cstdint, climits, cassert, cfloat, cstdio, cstdlib, cerrno seem to work fine * cmath and cstddef seem to error. So if we have in a program: // File: main.cpp #include <boost/mp11.hpp> #include <boost/charconv.hpp> int main() {} Under modular builds, this would be roughly equivalent to: // From boost/mp11.hpp #include <cassert> // insert here any headers required by mp11 macros #include <boost/mp11/detail/config.hpp> // the actual macro definitions import std; // generated by the standard header proxies you propose import boost.mp11; // generated by mp11 own headers // From boost/charconv.hpp #include <cmath> // insert here any headers required by charconv macros - this errors #include <boost/charconv/detail/config.hpp> // the actual macro definitions import std; // generated by the standard header proxies you propose import boost.charconv; // generated by charconv own headers int main() {} We can probably trim down most of the required stdlib headers so this is not a problem. Or just ifdef-out standard headers without the proxy headers that expand to import std.