Date: Tue, 14 Oct 2025 18:19:17 +0000
I think I see where you're coming from, but I am not sure I get everything in your argument just yet.
Is the point about control really about macros or about any control of the semantics of the code? E.g. wouldn't that be true of a compiler flag that control an aspect of code that isn't explicitly written explicitly in source?
-- Gaby
________________________________
From: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto:grafikrobot_at_[hidden]>>
Sent: Tuesday, October 14, 2025 12:25:57 PM
To: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Cc: sg15_at_[hidden]<mailto:sg15_at_[hidden]> <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; SG21 - Contracts <sg21_at_[hidden]<mailto:sg21_at_[hidden]>>; John Spicer <jhs_at_[hidden]<mailto:jhs_at_[hidden]>>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
On Tue, Oct 14, 2025 at 11:12 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
> The reason for this is that if you currently use a macro like MY_LIB_ASSERT(x), then you have control over what it does, even when your header is used by someone else.
* Can you think of a way to guarantee the above is true?
For the interest of the conversation, I would confess upfront that I don’t know everything (unlike some among us in this august forum).
One way I know of protecting my macros from interference from the “outside” is to use #pragma push_macro, supported by GCC<https://gcc.gnu.org/onlinedocs/gcc/Push_002fPop-Macro-Pragmas.html>, Clang, and MSVC<https://learn.microsoft.com/en-us/cpp/preprocessor/push-macro?view=msvc-170>, to protect my macro definitions. Then interfering with it would require any of similar means as interfering with any other portion of the code that I author without macros. But, then again, I didn’t make the claim of the impossibility you made earlier.
While you could use push_macro to protect changes to that one macro when you use it you would also provide some way to control the semantics of MY_LIB_ASSERT when used. It's very likely that control, which is what I think John was referring to, could be changed by any user (including yourself). One of those well used methods is defining, or not, NDEBUG. What I'm saying is that if you have any control anyway, not just you, can manipulate that control.
--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supongas Nada
-- Robot Dreams - http://robot-dreams.net<http://robot-dreams.net/>
Is the point about control really about macros or about any control of the semantics of the code? E.g. wouldn't that be true of a compiler flag that control an aspect of code that isn't explicitly written explicitly in source?
-- Gaby
________________________________
From: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto:grafikrobot_at_[hidden]>>
Sent: Tuesday, October 14, 2025 12:25:57 PM
To: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Cc: sg15_at_[hidden]<mailto:sg15_at_[hidden]> <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; SG21 - Contracts <sg21_at_[hidden]<mailto:sg21_at_[hidden]>>; John Spicer <jhs_at_[hidden]<mailto:jhs_at_[hidden]>>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
On Tue, Oct 14, 2025 at 11:12 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
> The reason for this is that if you currently use a macro like MY_LIB_ASSERT(x), then you have control over what it does, even when your header is used by someone else.
* Can you think of a way to guarantee the above is true?
For the interest of the conversation, I would confess upfront that I don’t know everything (unlike some among us in this august forum).
One way I know of protecting my macros from interference from the “outside” is to use #pragma push_macro, supported by GCC<https://gcc.gnu.org/onlinedocs/gcc/Push_002fPop-Macro-Pragmas.html>, Clang, and MSVC<https://learn.microsoft.com/en-us/cpp/preprocessor/push-macro?view=msvc-170>, to protect my macro definitions. Then interfering with it would require any of similar means as interfering with any other portion of the code that I author without macros. But, then again, I didn’t make the claim of the impossibility you made earlier.
While you could use push_macro to protect changes to that one macro when you use it you would also provide some way to control the semantics of MY_LIB_ASSERT when used. It's very likely that control, which is what I think John was referring to, could be changed by any user (including yourself). One of those well used methods is defining, or not, NDEBUG. What I'm saying is that if you have any control anyway, not just you, can manipulate that control.
--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supongas Nada
-- Robot Dreams - http://robot-dreams.net<http://robot-dreams.net/>
Received on 2025-10-14 18:19:22
