pointers - Stack members Vs heap members in C++ objects -

i apologize in advance i'm not after specific answer such. insight appreciated. comments (along code) below, outline observations, clarifications, , uncertainties. issue here lifetime of members.

class someclass {  int m_int; // primitive type. hardly ever see pointer   // class instances, always* seem see  someotherclass* m_some_other_class_instance_1;  // , not  someotherclass m_some_other_class_instance_2;   // lately, i've noticed std:: templates, doesn't seem  vector<double>* m_vector_instance_1;  // rather  vector<double> m_vector_instance_2; };  // got me thinking ...   void mainthread() {   someclass* some_class_instance_1 = new someclass();   // someclass instance on heap   // members (both <xx>_1 , <xx>_2) on heap   // hence members stay alive beyond scope of function (or they?)    someclass some_class_instance_2;   // someclass instance on stack   // piece of data relating someclass that's on heap what's pointed <xx>_1 members   // else still stay alive within scope of function    // in conclusion, using either case above, members of someclass instance stay alive intended period   // <xx>_1 members overkill?    // ah, ha, ha, ha, stayin' alive, stayin' alive ... } 

in terms of context, let's assume someclass not aware of other classes around , doesn't expect passing in/out now...so constructor might initialise members whatever , person wrote has no idea of how class may used. concern members staying alive.

i've read through these threads aren't quite related:

why should use pointer rather object itself?

class members , explicit stack/heap allocation

class members objects - pointers or not? c++

int m_int; // primitive type. hardly ever see pointer 

if saw int *m first reaction array of ints.

// class instances, always* seem see  someotherclass* m_some_other_class_instance_1;  // , not  someotherclass m_some_other_class_instance_2; 

you might want heap allocate object if need delay loading, , not have constructed when outer class is. reason might polymorphic reasons. if someotherclass base class in constructor might initialise different child class. if(some_condition) m_ptr = new child1(); else m_ptr = new child2(); again might want wrap in unique_ptr destruction automatic , don't leak.

 // lately, i've noticed std:: templates, doesn't seem  vector<double>* m_vector_instance_1;  // rather  vector<double> m_vector_instance_2; 

if holding on pointer of vector isn't owned class ptr isn't unexpected.

heap allocating vector (or other stl containers) doesn't make sense, partly because using them take pain out of dealing c-style arrays, , managing memory. underneath vector heap allocated.

  someclass* some_class_instance_1 = new someclass();   // someclass instance on heap   // members (both <xx>_1 , <xx>_2) on heap   // hence members stay alive beyond scope of function (or they?) 

yes, stack members stay alive until deleted. heap allocated ones must destroyed well, if doing manual allocation sure call delete, best wrap around unique_ptr or shared_ptr1

  someclass some_class_instance_2;   // someclass instance on stack   // piece of data relating someclass that's on heap what's pointed <xx>_1 members   // else still stay alive within scope of function 

this object , members destroyed when goes out of scope. not though of members pointers. should pointing heap allocated member has no other pointer have memory leak.

  // in conclusion, using either case above, members of someclass instance stay alive intended period   // <xx>_1 members overkill? 

i can't think of valid reason heap allocate stl container in context above. heap allocating other members might required, prefer not when can, , prefer using smart_ptrs when can.

  // ah, ha, ha, ha, stayin' alive, stayin' alive ... 

this c++, die slow , painful death.