Why doesn't #define SOMETHING TRUE work for #if? [duplicate] - c++

This question already has answers here:
C++, using #if TRUE conditional directive
(4 answers)
Closed 1 year ago.
The following code prints main.cpp:20:19: note: #pragma message: serial disabled. I had expected that "enabled" would be printed. What is wrong with the code?
int main()
{
#define SERIAL_ENABLED TRUE
#if SERIAL_ENABLED
#pragma message "serial enabled"
#else
#pragma message "serial disabled"
#endif
return 0;
}

TRUE is not defined. Use true.

Related

#if ! SOME_MACROS equivalent with #ifndef SOME_MACROS if SOME_MACROS always has numerical value [duplicate]

This question already has answers here:
What is the value of an undefined constant used in #if?
(3 answers)
Closed 12 days ago.
May be this is duplicate, I can't find similar question.
My surprise that, following code works for all three big compiler without error
#include <cstdio>
int main() {
#if !_LIBCPP_VERSION
std::printf("_LIBCPP_VERSION not defined");
#else
std::printf("_LIBCPP_VERSION defined and equal to %d", _LIBCPP_VERSION);
#endif
#ifndef _LIBCPP_VERSION
std::printf("_LIBCPP_VERSION not defined");
#else
std::printf("_LIBCPP_VERSION defined and equal to %d", _LIBCPP_VERSION);
#endif
}
Link to godbolt
My question is that: There check #if !_LIBCPP_VERSION - is always similar with #ifndef _LIBCPP_VERSION by standard C or C++?
They are not equivalent for numerical values.
SOME_MACROS
#if !SOME_MACROS
#ifndef SOME_MACROS
x
True
False
1
False
False
0
True
False
undef
True
True
Now, you said you only care about numerical values, so only the middle rows are relevant here. Yet we see a difference in those two rows.

preprocessor define with #pragma directive [duplicate]

This question already has answers here:
Pragma in define macro
(4 answers)
Closed 4 months ago.
I would like to do a #define which contains a #pragma directive but I got the following error.
Any idea?
#define FunctionPar_Begin typedef struct fpar { #pragma pack(4)
error C2121: '#': invalid character: possibly the result of a macro expansion
The one you probably want:
#define FunctionPar_Begin typedef struct fpar { _Pragma("pack(4)")
MSVC also allows for:
#define FunctionPar_Begin typedef struct fpar { __pragma(pack(4))
Clang/gcc also allow:
#define FunctionPar_Begin typedef struct fpar { __attribute__((packed, aligned(4)))

_ADDRESSOF(v) macro definition in VS2019 C++ [duplicate]

This question already has answers here:
Implementation of addressof
(4 answers)
Why and when is cast to char volatile& needed?
(2 answers)
Closed last year.
In <vadefs.h> you'll find the following definition for the macro _ADDRESSOF(v) in VS2019:
#ifdef __cplusplus
#define _ADDRESSOF(v) (&const_cast<char&>(reinterpret_cast<const volatile char&>(v)))
#else
#define _ADDRESSOF(v) (&(v))
#endif
I'd like to understand the first definition above, when __cplusplus is defined. Why does it work?

What is the difference between #ifdef VALUE vs #if defined (VALUE) [duplicate]

This question already has answers here:
Is #if defined MACRO equivalent to #ifdef MACRO?
(5 answers)
Closed 4 years ago.
#include<stdio.h>
#define MAX 0
int main()
{
#ifdef MAX
printf("MAX defined");
#endif
#if defined (MAX)
printf("MAX is defined");
#endif
return 0;
}
Both the #ifdef and #if defined give the same effect then what is the difference between them? I have not seen the disassembly code of these directives if you have seen then kindly try to explain that as well.
The difference is historical. Originally there was only #ifdef. The newer syntax is more flexible and allows combining tests with logical conditions, but in the simple form you can use them interchangeably.

stdbool.h: #define true true [duplicate]

This question already has answers here:
Why does clang's stdbool.h contain #define false false
(2 answers)
Closed 6 years ago.
stdbool.h contains this code:
#if __cplusplus < 201103L
/* Defining these macros in C++98 is a GCC extension. */
#define bool bool
#define false false
#define true true
#endif
Why does gcc need to redefine standard C++ types?
Although #define fnord fnord won't generally change the way the identifier fnord is processed, it will cause #ifdef fnord to report the macro as defined. If other code might do something like
#ifndef true
#define true 1
#endif
Having a #define true true would cause such conditional definition to be skipped.