Date: Wed, 5 Feb 2025 09:30:20 +0000
On Tue, Feb 4, 2025 at 11:07 PM Thiago Macieira wrote:
>
> > #include <vector> // fwd[std::vector]
>
> Let's not do that. Having something that works with both old and new
> preprocessors (because this is what it is) is a recipe for trouble because it
> would change what does become visible to the compiler. Or, for that matter,
> for the preprocessor itself: will the above define __cpp_lib_ranges?
We sort of already have this problem. For example:
#include <cstdint>
uint_fast32_t my_global_variable;
This will work fine on some compilers, and fail to compile on others.
> Not to mention that it's a horrible idea to do it with a comment. This might
> require major changes to it (I don't know whether comments are processed
> before #includes are expanded) and it might collide with comments people
> already put there. We don't want toolchains to suddenly start mis-interpreting
> a comment added in 1993.
So we make it very unique so that 'cppcheck' or whatever doesn't think
we're trying to talk to it.
>
> > #include <vector> // fwd[std::vector]
>
> Let's not do that. Having something that works with both old and new
> preprocessors (because this is what it is) is a recipe for trouble because it
> would change what does become visible to the compiler. Or, for that matter,
> for the preprocessor itself: will the above define __cpp_lib_ranges?
We sort of already have this problem. For example:
#include <cstdint>
uint_fast32_t my_global_variable;
This will work fine on some compilers, and fail to compile on others.
> Not to mention that it's a horrible idea to do it with a comment. This might
> require major changes to it (I don't know whether comments are processed
> before #includes are expanded) and it might collide with comments people
> already put there. We don't want toolchains to suddenly start mis-interpreting
> a comment added in 1993.
So we make it very unique so that 'cppcheck' or whatever doesn't think
we're trying to talk to it.
Received on 2025-02-05 09:30:26