In C++ you can use the address-of operator & to find the address of any lvalue^†. However, due to operator overloading this is not necessarily true. So what do you if you overload &?

C++, as usual, has introduced a solution for the problem it created with the standard library function std::addressof. How is this implemented, you may ask? Well, as you have to do is write the following elegant, readable, and simple snippet:

template<typename _Tp>
inline _Tp*
__addressof(_Tp& __r) _GLIBCXX_NOEXCEPT
{
  return reinterpret_cast<_Tp*>
(&const_cast<char&>(reinterpret_cast<const volatile char&>(__r)));
}

^† this is actually a lie. function names are considered lvalues. However, if you overload a function, then the program fails to compile if you provide that name to std::addressof because C++ is a poorly designed language that makes no sense.

I lied I learned how this works.

• template<typename _Tp> is C++'s overly-convoluted implementation of generic programming. The need for generic programming is very simple to motivate and in better languages these simple cases are extremely easy to understand, see for example https://www.youtube.com/watch?v=EcCTIExsqmI for how TypeScript handles some simple cases. In this case _Tp is just some generic type so that we don't have to define near exact copes of this function for int and long int and long long int and std::string and char and etc
• inline tells your compiler to try "inlining" any invocation of the function being declared. This means that the compiler will consider replacing any invocation of the function in your code with the function body. For small one-liners functions like this one the increased memory size of your resulting program isn't too big and avoiding the overhead of maintaining a call stack is worth it. It is important to understand that the compiler is not guaranteed to inline your function--the compiler may decide that inlining in some cases is not a a performance boost. (In fact, C++ compilers have always been allowed to inline any function is deems inline-able even if the keyword is not present. Modern compilers are extremely smart with inlining and it is no longer recommended to ever use the inline keyword unless you have profiled your code and determining that a small function is a bottleneck.)
• __BLIBCXX_NOEXCEPT is a macro defined specifically by the GCC compiler. This macro will not work on any other compiler unless you define the macro yourself. It is defined as follows:

#ifndef _GLIBCXX_NOEXCEPT
# if __cplusplus >= 201103L
#  define _GLIBCXX_NOEXCEPT noexcept
#  define _GLIBCXX_USE_NOEXCEPT noexcept
#  define _GLIBCXX_THROW(_EXC)
# else
#  define _GLIBCXX_NOEXCEPT
#  define _GLIBCXX_USE_NOEXCEPT throw()
#  define _GLIBCXX_THROW(_EXC) throw(_EXC)
# endif
#endif

noexcept is a keyword introduced in C++11 that flags to the compiler that the function is not expected to throw any errors which allows the compiler to optimize the function a bit. (If a function declared with noexcept does end up throwing an error your program will simply terminate.) It has since deprecated the throw keyword which was used for similar purposes (you would use it like throw(EXCEPTION_1, EXCEPTION_2) to indicate that the function was only supposed to throw one of the two listed exceptions), except the program would exhibit undefined behavior if a function declared with throw() threw an any error because C++ is a bad language. The GCC compiler introduced this macro so that you could write code that would use noexcept if you are compiling to C++11 and throw() if you are using earlier versions of the language.

• reinterpret_cast is a cast that does not change the bits in the data being casted. Ordinarily, if you cast a float to an int, your computer will perform a calculation to change that float into an int with a value that is as close to the original float value as possible. But if you use reinterpret_cast to cast a float to an int, the bits used to represent the float will now represent whatever number that an int on your specific computer architecture will be for the string of bits that used to represent a float.
• const_cast is a cast that allows you to cast of const-qualified value into one without the const qualification.

So, the point here is that we want to cast whatever data type is given to the function as a char. Why a char? There are two reasons. The first is that the &* operator cannot be overloaded for built-in primitive types like char, int, etc so we can use & to take the address of them. The other reason is because data in your computer has to adhere to what are called "alignment requirements". That is, computer architecture demands that the number of bits between certain data types be a certain amount.

Suppose you had a variable that was some 8-bit data type and, in storage, immediately to its right is are 32 bits used to represent a 32-bit integer. Now suppose you casted your 8-bit data type to a 32-bit integer. Well, now you have an overlap in bits! This is no good because if we write to both variables, we will actually be manipulating both variables in unexpected ways. So reinterpret_cast won't actually look at the same the bits as before, and it be looking at a new spot where it won't have this "overlap". We can avoid this problem by casting to a new data type that won't cause this sort of overlap to occur. It so happens that char is tied for the least-strict alignment requirements of any data type in your computer architecture so we will avoid any overlapping problems entirely by casting to char.

So what we do is reinterpret_cast whatever type was given as a const volatile char reference. Why a reference? Because we are only allowed to use & on lvalues, but the results of casts are almost always treated as rvalues, which the one exception being casts to lvalue refererences. (This is likely to be consistent with the fact that functions which return lvalue references are treated as lvalues, ie, all computations of lvalue references are treated as lvalues). Why are we using the const and volatile references? Because the generic value given to the function might have const and volatile qualifiers and C++ does not allow reinterpret_cast to strip these qualifiers away from a value.

Now, why do we have the intermediary const_cast<char&> where we strip the volatile and const qualifiers? Why don't we just do return reinterpret_cast<_Tp*>(&reinterpret_cast<const volatile char&>(__r));? Well, according to cppreference, "If the operand is .... type T, & creates and returns a prvalue of type T* with the same cv qualification". Hence, the cast back into a reinterpret_cast<_Tp*> results in an attempt to strip a cv-qualification. const_cast is one of the few situations where C++ allows you to explicitly strip a cv-qualification, so we use it. We could also use an ordinary C-style cast ((char&) instead of const_cast<char&>) but C-style casts are considered unfashionable.

In short, we are using a special kind of cast that does not change the bits present in the underlying data to cast the given value into a built-in type that won't cause alignment issues and can be used with & without fear of overloading. We have use a lot of intermediary casts in order to satisfy the C++ compiler when a cv-qualified value is given to the function. The function uses the inline and noexcept/throws() keywords so that the compiler will try to super-optimize the function. We use C++'s implementation of generic programming so we can define the function for all possible types.