C++ Logo


Advanced search

Re: [std-proposals] import std and streams macros

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Sun, 18 Feb 2024 12:48:09 -0500
On Sun, Feb 18, 2024 at 12:38 PM SM via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello everyone,
> I encountered this issue and suggest the following ideas.
> [...]
> In C++23, import std was introduced to facilitate the use of standard
> libraries.
> However, it does not expose macros, so a user have to include the
> corresponding header files again, for example:
> #include <cstdio> // for stderr
> [...]
> To resolve other C streams macros, I propose global variables, std::in,
> std::out, and std::err as substitutes for stdin, stdout, and stderr,
> respectively.
> The following papers try to solve the similar macro issues:
> 1. P2654 Macros And Standard Library Modules - import should suffice
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2654r0.pdf>
> 2. P2884 assert Should Be A Keyword In C++26 - Supporting standard C++23
> macros in module std
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2884r0.pdf>
> 3. P2883 offsetof Should Be A Keyword In C++26 - Supporting standard
> C++23 macros in module std
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2883r0.pdf>

Rather than coming up with a different ad-hoc solution for each macro in
the Standard Library (assert, offsetof, stdin,...), we should be looking
for a solution that Just Works for all macros. "Just keep using #include"
is the most obvious solution; but maybe someone can find another. I don't
think a shotgun approach of ad-hoc solutions is the right way to go, at all.

(I'd had a vague idea that this was the problem that `import std.compat;`
was intended to solve; but no, that just puts entities into the global
namespace in addition to `std`. It doesn't do anything about macros.)

The same question was asked on StackOverflow last January. No answers yet,
except for the obvious one of "just keep using #include":

("Just keep using #include" is not a bad idea, btw. It's certainly what I
recommend for production codebases, now and for the foreseeable future.)

my $.02,

Received on 2024-02-18 17:48:23