A truly inquisitive and resilient mind doesn't stop at "what" something is or "how" it works—but seeks to understand "why" it exists, why it works that way, and why it matters.
The first and foremost task of a student is to figure out the purpose of why he learns any specific subject. And once he gets the idea - the how follows. The basic purpose of a Guru is to help his disciples find that why.
It's true for every profession that teaches skills. We must not only learn a subject from what’s and how’s point of view, but also why's point of view.
What… How… Why…
Here's a concise breakdown of this triad of understanding:
What → Identification
"What is this concept, object, or phenomenon?"
→ Descriptive knowledge.
How → Mechanism
"How does it function or occur?"
→ Technical/operational knowledge.
Why → Purpose or cause
"Why does this happen? Why was it designed this way? Why should I care?"
→ Philosophical, causal, or ethical understanding.
Nurturing the "why" mindset leads to:
- Original thinking, not just replication.
- Deeper learning, rooted in curiosity.
- Innovation, since questioning assumptions often sparks breakthroughs.
- Purpose-driven action, not just routine.
It’s the same mindset behind scientific inquiry, design thinking, and even spiritual introspection. So yes—let’s raise thinkers, not just doers.
Now let me tell you about one of my own experiences.
I joined NOKIA, Bharat and got my first taste of Symbian 60 there. There is a concept in Symbian C++ - the two phase constructor which helps avoid memory exceptions while constructing a C++ object.
I was curious about it and asked many employees in NOKIA, but got the standard answer that this is the norm. Then in Japan in 2007, I studied a bit of Boost library, especially the different types of pointers and understood why Symbian people did that - because there was no template concept in the early days of C++ and hence there was no smart pointer - so the Symbian community had no other way to avoid memory exception during construction of C++ object because the destructor works only for a fully constructed object. Note that early mobile phones did not have huge memory… hence even an insignificant memory leak was disastrous.
Read…
Read…
Here's a write up on the Symbian two phase constructor.
Symbian used two-phase construction partly because:
1. Early C++ lacked features like templates (pre-C++98 days).
2. So, smart pointers like std::unique_ptr, std::shared_ptr, or even std::auto_ptr were unavailable or unsafe.
3. This made automatic resource management difficult, especially in the face of exceptions or “leave” behavior.
🔍 The primary reason for two-phase construction was:
> Symbian's custom exception handling mechanism (based on “leave” and “cleanup stack”) and restricted runtime environment
📌 Why Not Use Traditional RAII?
RAII (Resource Acquisition Is Initialization) — the modern C++ idiom using constructors/destructors — was impractical in early Symbian because:
1. No Exceptions → constructors couldn’t safely fail.
2. No Smart Pointers → no automatic cleanup of heap objects.
3. Low-Memory Targets → needed ultra-predictable, minimal-overhead code.
4. Destructors only run on fully constructed objects → Symbian needed a way to clean up partially constructed objects.
📚 Cleanup Stack = Manual Smart Pointer
Symbian’s cleanup stack was a manual alternative to smart pointers, ensuring that dynamically allocated objects or memory could be cleaned up reliably if a “leave” occurred.
🔁 Two-Phase Construction Solved All This By:
Phase Role Fails?
Constructor Allocates memory only No
ConstructL() Initializes and may leave Yes
If ConstructL() failed, the partially constructed object could be safely deleted via cleanup stack.