STD::_REFERENCE_WRAPPER_BASE(3cxx)

🌸 NAME 🌸

std::_Reference_wrapper_base< _Tp > — bestie, this is a libstdc++ internal template struct, and she's the one doing the behind-the-scenes paperwork for std::reference_wrapper. 💅

---

✨ SYNOPSIS ✨

#include <refwrap.h>

Ok so first things first, she does not stand alone, she's part of a whole friend group. She inherits from:

• std::_Weak_result_type< _Tp >
• std::_Refwrap_base_arg1< _Tp, typename >
• std::_Refwrap_base_arg2< _Tp, typename >

And she's inherited by:

• std::_Reference_wrapper_base_memfun< remove_cv< _Tp >::type >
• std::_Reference_wrapper_base_memfun< _Tp, bool >

It's giving family tree. It's giving generational trauma but make it templates. 🦋

---

💖 Detailed Description 💖

template<typename _Tp>
    struct std::_Reference_wrapper_base< _Tp >

So what does she actually do, you ask? Literally the description says it all:

"Derives from unary_function or binary_function when it can. Specializations handle all of the easy cases. The primary template determines what to do with a class type, which may derive from both unary_function and binary_function."

No cap, that's the whole vibe: she checks if she can derive from unary_function or binary_function, and when she can, she does. The specializations are the ones picking up all the easy cases (they ate, honestly), while the primary template is the main character handling class types — and those class types might be deriving from unary_function and binary_function at the same time. So she's out here figuring out what to do with a messy class type that wants both. 😭

📌 Definition at line 214 of file refwrap.h.

---

👑 Author 👑

Generated automatically by Doxygen for libstdc++ from the source code. So like, nobody wrote this by hand, it just spawned. Iconic behaviour, fr fr. 🙈

---

That's the whole page, bestie — from the 3cxx manual section, libstdc++ edition, all documented and dusted. Go forth and template. 💜✨🎀