std::ios_base::ios_base(3)

✨ std::ios_base::ios_base ✨

okay bestie, so this is the std::ios_base::ios_base manual page from the C++ Standard Library — aka the origin story of how stream base objects get (and don't get) constructed 💅 buckle up.

🌸 SYNOPSIS 🌸

private:                                      (until C++11)
ios_base( const ios_base& );
public:                               (1)     (since C++11)
ios_base( const ios_base& ) = delete;
protected:                                (2)
ios_base();

so here's the tea on these two constructors, no cap 🫖

1. the copy constructor is private (until C++11) and deleted (since C++11) — literally because streams are not copyable, periodt. you cannot duplicate a stream, it's giving one-of-a-kind main character energy 👑
2. the default constructor is protected: only derived classes may construct std::ios_base. and like, the internal state is undefined after construction 😭 so the derived class must call std::basic_ios::init() to complete initialization before first use or before the destructor — otherwise the behavior is undefined. not me warning you twice, but fr fr, that's the rule 💀

⚠️ okay so the undefined-behavior part is serious: skip that init() call and everything's cursed, no takebacks.

🦋 NOTES 🦋

the same whole situation applies to the constructors of the next class in the I/O hierarchy, std::basic_ios. and the further-derived classes (std::istream and std::ostream) are always constructed with a concrete stream buffer object and call std::basic_ios::init() — possibly more than once, iykyk — to complete initialization of their virtual base. it's giving teamwork honestly 🫶

🎀 Defect reports 🎀

the following behavior-changing defect reports were applied retroactively to previously published C++ standards. (yes, they went back and fixed the lore 📜✨)

• LWG 50 — applied to C++98. behavior as published: the copy constructor was not specified. correct behavior: specified as private.
• LWG 220 — applied to C++98. behavior as published: the behavior of destroying a std::ios_base object before calling its init() was not clear. correct behavior: the behavior is undefined in this case.
• LWG 1249 — applied to C++98. behavior as published: initialization did not need to be completed before first use. correct behavior: initialization also needs to be completed.

like, they really said "let's clarify the vibes" and honestly? slay 🌈

that's the whole page bestie — every flag, every caveat, every DR, all accounted for 💖

and that's a wrap! this iconic little page comes to you from cppreference.com, dated 2024.06.10, under the title std::ios_base::ios_base(3). go forth and call your init(), queen 🧚💜