@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

@NeilMonday, Could you elaborate a bit more on this. The constexpr is already in a namespace:

snmalloc::DEBUG

Are you including the whole namespace, and then getting conflicts?

@NeilMonday, Could you elaborate a bit more on this. The constexpr is already in a namespace:

snmalloc::DEBUG

Are you including the whole namespace, and then getting conflicts?

In my project, I have a preprocessor definition "DEBUG=1" for debug builds. So, I think this is conflicting with the snmalloc::DEBUG even though it is in its own namespace?

is it possible to use DDEBUG or other prefixed DEBUG macro in your project?

Or use #pragma macro_push to guard around the inclusion of snmalloc header?

See https://gcc.gnu.org/onlinedocs/gcc/Push_002fPop-Macro-Pragmas.html

is it possible to use DDEBUG or other prefixed DEBUG macro in your project? Or use #pragma macro_push to guard around the inclusion of snmalloc header?

Sure, I will look at some alternatives and see what I can do.

So at one point I tried to use the convention that

• constexpr were capitalised, and
• macros were all caps and preceeded with SNMALLOC_.

So if we did

snmalloc::Debug

Then I would be happy, and I think that would no longer conflict with the pre-processor expansion. That would hopefully fix your issue. It would tidy the code to the unwritten convention.

I think snmalloc::Debug would be a great solution. Let me try that now.

While looking online it seems like #define DEBUG is a common thing in some generic C++ examples (even though it isn't a default from msvc or gcc). So it seems like it could happen to someone else in the future.

@NeilMonday if you're happy can you mark as "Ready for review" and we'll merge this.

@SchrodingerZhu thanks for the suggestions. I think it is probably best to avoid DEBUG. If one person has an issue, others will.