🧠 Concepts to Master (The "Why")

• Why std::vector of Pointers (Client*) vs Objects?

<aside> ⚠️

Memory Management Reality Check Understanding pointer semantics is critical for IRC server stability.

</aside>

• [ ] Polymorphism & Lifetime Independence: When you store Client*, you maintain a reference to an object that exists elsewhere (likely in a Server's master client list). Multiple channels can point to the same client without copying.
• [ ] Avoiding Object Slicing: If you stored Client objects directly in a vector, copying them would slice off derived class information (if you ever extend Client).
• [ ] Dynamic Allocation Control: Clients are created on the heap when a connection is established and destroyed when disconnected. Channels should not own clients—they merely reference them.
• [ ] Performance: Copying entire Client objects every time you add/remove from a channel would be expensive. Pointers are 4-8 bytes; objects could be hundreds.
• [ ] Consistency: When a client changes their nickname, all channels see the update immediately because they point to the same object.

The Trade-off:

• You must ensure pointers remain valid (the Server must notify channels when a client disconnects).
• In C++98, no smart pointers—you manage lifetimes manually.

• How to Handle std::map Iterators in C++98 Loop Syntax

<aside> 📚

C++98 Iterator Constraints No range-based for loops. No auto. Manual iterator management only.

</aside>

• [ ] Declaration Syntax: You must explicitly declare the iterator type:
  • Example concept: std::map<std::string, Channel*>::iterator it;
  • For const access: std::map<std::string, Channel*>::const_iterator it;
• [ ] Loop Structure:
  • Initialize: it = myMap.begin()
  • Condition: it != myMap.end()
  • Increment: ++it (prefer pre-increment for iterators)
• [ ] Accessing Elements:
  • it->first gives you the key (e.g., channel name)
  • it->second gives you the value (e.g., Channel* pointer)
• [ ] Erasing During Iteration (Critical in C++98):
  • map.erase(it) invalidates the iterator!
  • Safe Pattern: Store the next iterator before erasing:
    • Pseudocode: next_it = current_it; advance next_it; erase current_it; current_it = next_it;
  • Or use the return value pattern (if your STL supports it)
• [ ] Finding Elements:
  • Use map.find(key) which returns an iterator
  • Always check if (it != map.end()) before dereferencing

Common Pitfalls: