Inheritance and Arrays

I have an abstract base class, call it ABC. It has two derived classes, say Derived1 and Derived2. In another class, I need an array of objects of either Derived1 or Derived2. The problem is I don't know if the array elements should be of type Derived1 or Derived2 until run time. (I have a variable called "mode", and the value of mode determines if the array should contain Derived1 or Derived2 objects.) I can't seem to create an array of ABC pointers since you can't create instances of an abstract class. So how can I create this array?

Thank you!!

can you do this:

class C and D derived from base class B which is derived from abstract class A. Then use array of pointers to class B.

I suppose I could, or I could just make A not an abstract class and derive C and D directly from A. I just liked the idea of forcing derived classes to include certain functions... oh well, I suppose the compiler will catch it if another programmer tries to call a non-existant function! :)

You can make an array of ABC*, just make sure never to instantiate them as type ABC (i.e. ABC* y = new ABC; is an error). Instead, instantiate them as the derived type (ABC* y = new Derived1).

Cheers

But I also don't know the size of the array until runtime. C++ doesn't seem to like an array declaration like:

ABC* myarray[size];

when size is not a constant. The only way I know how to create such an array is with new.

For that matter, even when I decided to make ABC not abstract and just a regular parent class, I can't seem to get the array to work. All of its members are getting cast as type ABC, not as the derived type! (I can show you some code but I've tried quite a few things, so I don't know how much it will help!)

Yikes, this is getting messy! :eek:

here's a reasonable discussion of pointers to base classes:

http://www.stud.fim.ntnu.no/~oystesk/CPP/htm/ch13.htm

to use an array of base class pointers of unkown size I suspect you would need to do something like this:

ABC * ptrArray = new ABC *[size];

where size is a variable. Now ptrArray will act as an array of pointers to type ABC which is the base class for Derived1 and Derived2. No instance of ABC ever need be declared, so ABC can be abstract if necessary. See above reference for discussion.

Quote:

---

C++ doesn't seem to like an array declaration like:

ABC* myarray[size];

when size is not a constant.

---

An array size has to be known at runtime, so the compiler can set aside the memory. Otherwise, you have to dynamically allocate the memory.

Applying what Zack L. said:

int size = 0;
int mode = 0;
cin>>size>>mode;

if(mode==10)
ABC* y = new Derived1[size];
else
ABC* y = new Derived2[size];

yStud --

When I tried

Code:

---

if (mode == 1)
  ABC* ptrArray = new Derived1[size];
else
  ABC* ptrArray = new Derived2[size];

---

It's still treating the elements of ptrArray as ABC pointers, not as Derived1/Derived2 pointers.


elad --

When I tried

ABC * ptrArray = new ABC *[size];

I got an error that I was trying to do an illegal implicit cast from ABC* to ABC**. So I changed it to

ABC ** ptrArray = new ABC *[size];

and later I have the code:

Code:

---

for (int i=0; i<size; i++) {
                if (mode == 1)
    ptrArray[i] = new Derived1;
                else
    ptrArray[i] = new Derived2;
}

---

and it still treated the members of ptrArray as ABC type, not derived types. But thanks for that link -- I will go look through that and maybe I can find something to help me out!

"and it still treated the members of ptrArray as ABC type, not derived types."

That's the whole point of polymorphism: you can use pointers to base class objects to point to derived class objects. If you don't need polymorphic behaviour, why not just dynamically create an array of pointers to Derived1 or Derived2 objects?
-----

ABC ** ptrArray = new ABC *[size];

If you have an array of int's, then a pointer to the array points to the first element which is an int, so the type of the pointer is pointer to int, or int*. If the array is an array of int pointers, then a pointer to that array points to the first element which is of type int*. So, the pointer to that array must be type pointer to int*, or int**.

use std::vector<ABC *> v;

to add a Derived1 v.push_back(new Derived1(/*args if needed*/));

any calls on methods of ABC will call the Derived method iff those methods are virtual.

If you need to use something that's not in the ABC you need to use dynamic_cast<Derived1 *>(v[3]); This will give you a pointer iff v[3] actually points to a Dervived1.

Naturally, you need to rember to delete each element.

7stud --

Quote:

---

"and it still treated the members of ptrArray as ABC type, not derived types."

That's the whole point of polymorphism: you can use pointers to base class objects to point to derived class objects. If you don't need polymorphic behaviour, why not just dynamically create an array of pointers to Derived1 or Derived2 objects?

---

Hmm, then maybe I don't understand polymorphism like I thought I did (which is always a possibility!). I thought the purpose of arrays of base class pointers is so they can store objects of the derived types, and the functions of the derived types will be called -- the example I always hear of is an array of screen objects, each with its own draw method.

Granted, I don't need to mix the types in my array. But I use the array so many times, it seemed silly to create two arrays of the different derived types and each time I need to use them, check the mode to see which array to use. Or alternatively, have two functions with the exact same code except for the array types, because these two derived classes have the same functions. In my particular instance, the derived types have functions that the base class does not. The way I know the pointers in the array are being treated as base classes is because the compiler is saying those functions are undefined.

So perhaps I should ask a new question -- is there a way to dynamically set the type of the array? I've tried code like

Code:

---

if (mode == 1)
  Derived1 ptrArray = new Derived1[size];
else
  Derived2 ptrArray = new Derived2[size];

---

but after the if statement I get errors saying ptrArray wasn't initallized. (I don't remember the exact code I tried, I deleted it a while ago.) Does that make any sense or am I just making things more confusing?

Oops I just realized why that if statement didn't work -- the array only exists in the scope of the if! Still, is there a way to do what I'm asking? Or am I just going to have a bunch of duplicate code or if statements to check the mode?


grib --

Your post just appeared when I hit reply. While your code does look promising (I do seem to remember seeing dynamic_cast somewhere), I'd still have the same problem I just described -- I'd have to keep checking the mode to see what type I need to cast! What I really need to know is, is there a way to avoid this?

Thanks for all the help you guys have given me!

The derived class' function will get called if the base class' function was declared as 'virtual'.

There is no real good way to dynamically set the array type. You could use void* to get generic pointers and then dynamic_cast them each time you make a function call, but that is really a type-unsafe and scaled down version of what you were doing.

Look some more into virtual functions, and RTTI, and I think you'll find what you're looking for.

Cheers

Hey! I think I fixed it!

Grib's comments got me to thinking... since the functions I needed were not in the base class, I just put them in the base class, made them virtual, and had them print an error message to the screen. Since the code compiled and no error messages were printed, I think it's working! If you're interested here's how I finally created that array:

Code:

---

ABC ** ptrArray = new ABC* [size];
for (int i = 0; i < size; i++) {
                if (mode == 1)
                        ptrArray[i] = new Derived1;
                else
                        ptrArray[i] = new Derived2;
}

---

Of course now my program's crashing inside one of the derived classes -- you fix one error just to get a new one! :rolleyes: Oh well, at least one class seems to be working :) Thanks again for all your help!

Let's see if I can work through this correctly. NOT compiled, so may well have errors in it.

Code:

---

1:    //modified from TYC++ 3rd edition  example 13.9
2:
3:    #include <iostream>
4:
5:    using namespace std;
6:
7:    class Shape
8:    {
9:    public:
10:      Shape(){}
11:      ~Shape(){}
12:     
13:     
14:      virtual void Draw() = 0;
15:    private:
16:    };
17:    //yes, you can define pure virtual functions
18:    void Shape::Draw()
19:    {
20:      cout << "Base class method called but not base class object initialized\n";
21:    }
22:
23:    class Circle : public Shape
24:    {
25:    public:
26:          Circle(int radius):itsRadius(radius){}
27:          ~Circle(){}
28:         
29:         
30:          void Draw();
31:    private:
32:      int itsRadius;
33:      int itsCircumference;
34:    };
35:
36:    void Circle::Draw()
37:    {
38:      cout << "Circle drawing routine here!\n";
39:      Shape::Draw();
40:    }
41:
42:
43:    class Rectangle : public Shape
44:    {
45:    public:
46:          Rectangle(int len, int width):
47:            itsLength(len), itsWidth(width){}
48:          ~Rectangle(){}
49:         
50:         
51:         
52:         
53:          void Draw();
54:    private:
55:      int itsWidth;
56:      int itsLength;
57:    };
58:
59:    void Rectangle::Draw()
60:    {
61:      for (int i = 0; i<itsLength; i++)
62:      {
63:          for (int j = 0; j<itsWidth; j++)
64:            cout << "x ";
65:
66:          cout << "\n";
67:      }
68:     
69:    }
70:
71:
72:    class Square : public Rectangle
73:    {
74:    public:
75:          Square(int len);
76:         
77:          ~Square(){}
78:   
79:    };
80:
81:    Square::Square(int len):
82:      Rectangle(len,len)
83:    {}
84:
85:   
86:     
87:
88:   
89:     
90:   
91: 
92:
93:    int main()
94:    {
95:      int choice;
96:      bool fQuit = false;
97:      Shape * sp;
98:       
99:      while (1)
100:      {
101:        cout << "(1)Circle (2)Rectangle (3)Square (0)Quit: ";
102:        cin >> choice;
103:
104:        switch (choice)
105:        {
106:            case 1: sp = new Circle(5);
107:            break;
108:            case 2: sp = new Rectangle(4,6);
109:            break;
110:            case 3: sp = new Square (5);
111:            break;
112:            default: fQuit = true;
113:            break;
114:        }
115:        if (fQuit)
116:            break;
117:
118:        sp->Draw();
119:        cout << "\n";
120:      }
            //the above uses a pointer to an abstract base class to call methods for objects of classes derived from that abstract base class.  In the case of Circle, it also demonstrates that you can call virtual base class methods, even pure virtual base class methods, if you want/need to.
            //now I'll try to create an array of base class pointers to store data, then use the data, then delete the memory
         
          Shape * arrayShapePtrs[4];
          for(int i = 0; i < 4; i++)
          {
                    cout << "(1)Circle (2)Rectangle (3)Square";
                    cin >> choice;
 
                    switch (choice)
                    {
                        case 1:
                            sp = new Circle(5);
                            break;
                        case 2: sp = new Rectangle(4,6);
                            break;
                        case 3: sp = new Square (5);
                            break;
                        default:
                              break;
                    }
                    arrayShapePtrs[i] = sp;
            }

            for(i = 0; i < 4; i++)
              arrayShapePtrs[i]->Draw();
         
            for(i = 0; i < 4; i++)
              delete arrayShapePtrs[i];
           
      //and now I'll try to use user input to determine size of array of pointers to Shape, use the pointers and delete the memory
      int size;
      cout << "input number of shapes to use" << endl;
      cin >> size;

      //an array of pointers on the heap
      Shape ** pointers;
      pointers = new Shape * [size];

      //fill up the array
      for(i = 0; i < size; ++i)
      {
              cout << "(1)Circle (2)Rectangle (3)Square";
              cin >> choice;
 
                    switch (choice)
                    {
                        case 1:
                            sp = new Circle(5);
                            break;
                        case 2: sp = new Rectangle(4,6);
                            break;
                        case 3: sp = new Square (5);
                            break;
                        default:
                              break;
                    }
                pointers[i] = sp;
          }
       
          //use the array of pointers
          for(i = 0; i < 4; i++)
              pointers[i]->Draw();
         
            //delete memory for the individual pointers stored in the array
            for(i = 0; i < 4; i++)
              delete pointers[i];
       
            //delete memory for the array itself
            delete [] pointers;
     
      //and if I didn't make any mistakes, I'm done   
      return 0;
}

---

"Hmm, then maybe I don't understand polymorphism like I thought I did (which is always a possibility!)."

It sounds like you understand polymorphism just fine.

When you said:

"It's still treating the elements of ptrArray as ABC pointers, not as Derived1/Derived2 pointers."

I guess you meant you weren't getting the polymorphic behavior you wanted.

"since the functions I needed were not in the base class, I just put them in the base class, made them virtual, and had them print an error message to the screen. "

Yes, if you want polymorphic behavior, the function has to be in the base class and it has to be declared virtual. Declaring the function virtual means, you want to have what's called "dynamic binding": the function call is determined at run time by what type of object the pointer points to. If the function isn't declared virtual, you get a static call to the base class function: the function call is determined at compile time based on the type of the pointer--so no polymorphism. If you don't declare the function at all in the base class, then you're statically trying to call a non existent base class function, so I would think the compiler would go looking for the function at compile time, fail to find it, and give you an error. :)

First of all you should test your ideas on single objects - not as arrays of pointers to derived classes. You should know better than that. The idea behind the virtual function is that whenever base class code calls it, immediately it jumps to the derived version. Simple as that. Elad's example was good but he forgot to make the Circle::Draw virtual also, important for derived classes of the circle and so on. But anyhoo, you've got it now.

Code:

---


struct ABC {
virtual ABC(){self() = this;}
virtual ~ABC(){}
ABC * self(){return _self;}
virtual void talk(){cout << "ABC" << endl;}
private :
ABC * _self;
};

struct DEF : ABC {
virtual DEF(){}
virtual ~DEF(){}
virtual void talk(){cout << "DEF" << endl;}
};

struct HIJ : ABC {
// perhaps no ancestors for this one?
HIJ(){}
~HIJ(){}
virtual void talk(){cout << "HIJ" << endl;}
};

//

int main(){

DEF def;
ABC * t = def.self();
t->talk();
return 0;
}

---

as a side note totally unrelated to this current post, I still think someone ought to make it so smilies are disabled inside code brackets

It is my understanding that if a function is declared as virtual in the base class and another class is derived from that class, then the function in the derived class is virtual as well, by inheritance, and there is no need to declare the function virtual in the derived class (it isn't wrong to declare it virtual in the derived class, but it isn't necessary either). But I'm not always correct in my understanding, so look it up in your favorite reference.

Quote:

---

Originally posted by grib
use std::vector<ABC *> v;

to add a Derived1 v.push_back(new Derived1(/*args if needed*/));

any calls on methods of ABC will call the Derived method iff those methods are virtual.

If you need to use something that's not in the ABC you need to use dynamic_cast<Derived1 *>(v[3]); This will give you a pointer iff v[3] actually points to a Dervived1.

Naturally, you need to rember to delete each element.

---

I agree with the std::vector idea, but I'd take it a step further. Download a good supplimentary library, like Boost and use a vector of shared_ptr instead. Unlike std::auto_ptr, boost::shared_ptr is container-safe (and will almost certainly be included in the next revision of the standard library).

The benefit here is that you never have to manually delete any pointers, and you get exception safety (as long as you don't try to instantiate a pointer as a temporary in a function call, you can't leak memory even if an exception is thrown).

Arrays and pointers are the two most dangerous features of the language; they're where your memory leaks will occur. "When you learn C, you spend most of the time learning how to use arrays and pointers; when you learn C++, you spent most of the time learning how to avoid using them." This is not to suggest that you forget about learning pointers & arrays, but rather, that you learn them, and then learn their drawbacks as well.

It is not easy to try to make allocating objects within an array of object pointers exception-safe (e.g. if you are allocating 100 objects, and object 53 throws an exception at creation, you need to destroy objects 1-52).

For example, this is NOT exception safe:

Code:

---

// Assume MyObject** array is a member of MyClass

MyClass::MyClass(){
  array = new MyObject* [100];  // Line A
  for (int i = 0; i < 100; i++)
    array[i] = new MyObject;  // Line B
}

---

Now suppose an exception occurs at Line B when i = 50. What happens?

1) ~MyClass() will NOT be called, because the constructor didn't finish.
2) The *variable* array (which is really a pointer to the first element of an array of pointers) is freed.
3) The memory allocated in Line A (the array of pointers itself) is NOT freed.
4) The 50 objects that did get constructed in Line B are not destroyed, and their memory is not freed.

In this example, you leak 50*sizeof(MyObject) + 100 * sizeof(MyObject *), because you allocated 50 objects and 100 pointers that can't be freed.

Note, it is certainly possible to make it exception safe, by catching the exception immediately, deleting all the objects that were successfully made, and then rethrowing the exception (assuming you want to abort the constructor when you can't allocate). But this can take up a lot of code -- the cleanup code would take up more space than the allocation code! Further, there's a more elegant way of achieving the same goal. The elegant way also has the benefit that it can't leak resources for other reasons -- e.g. a malformed destructor for the above method could also be a source of a resource leak, or a member function that did array operations, etc. You can think of it as plugging many possible leaks at once.

The elegant way would be:

Code:

---


typedef boost::shared_ptr<MyObject> MyObjectPtr;
typedef std::vector<MyObjectPtr> MyObjectVector;

// assume MyObjectVector mov is a member of MyClass
MyClass::MyClass(){
  mov.reserve(100);            // Line A
  for (int i = 0; i < 100; i++)
    mov.push_back(MyObjectPtr(new MyObject));  // Line B
}

---

Assume the exception happens just as before. Now what happens?

1) ~MyClass() will still not be called, because the constructor didn't finish. (which is good; destroying a half-built object is not a good idea)
2) The variable mov is freed. Because mov itself finished construction, it is destroyed (its destructor is called and its memory is released).
3) As mov is destroyed, each of the 50 smart pointers that constructed properly is deleted by vector's destructor.
4) The memory (potentially) allocated in Line A is freed with the destruction of the vector object.
5) When each of the smart pointers is deleted, its reference count drops to zero (it was the last pointer to that object) so it frees the memory of the 50 MyObject objects.

Now, you have the same functionality as before, but you are protected against memory leaks, even when an exception is thrown partway through construction.

This also has the added benefit that both the vector and the pointers "clean up after themselves", so you don't need to remember to destroy them.

Do note, that your objects (of class MyObject) MUST NEVER throw an exception in their destructors. This is a general rule; destructors should never throw exceptions.

Oh, there is one case in which shared_ptr cannot help you if an exception is thrown, and that is this case:

Code:

---

myFunction(MyObjectPtr(new MyObject),myFunction2());

---

In this case, we know that "new MyObject" must be evaluated before MyObjectPtr's constructor, but compilers can do the call to myFunction2() anytime. So if your compiler executed in this order:

1) new MyObject
2) myFunction2()
3) MyObjectPtr::MyObjectPtr()

then you could leak resources if myFunction2() throws an exception. You should NEVER use this code like this, even if you can assure me that your compiler doesn't use that particular order of execution. The compiler is ALLOWED to do things in that order. Yes, there are 3 different orders that it could execute in, and that is the least likely for a compiler to use, but your code should work under ANY legal compiler, and the above order is legal if unusual.

The safe way to do the above call is:

Code:

---

MyObjectPtr p(new MyObject);
myFunction(p,myFunction2());

---

Now the object is destroyed even if myFunction2() throws.

By the way, the following code is safe, because the compiler has no freedom in order of executions: It must first call new, then MyObjectPtr's constructor, then vector::push_back(). There is no place for an exception to occur between the call to new and the call to the smart pointer's construction.

Code:

---

mov.push_back(MyObjectPtr(new MyObject));

---

Do be warned now that shared_ptr isn't a magic bullet that stops all possible leaks. There are ways you can force a memory leak, even with shared_ptr; the main one is an object with a shared_ptr to itself (e.g. say you have a shared_ptr named A that points to an object B, which has a shared_ptr that is a copy of A). In that case, you'll always leak (B can't be destroyed until A's reference count is zero, but A's reference count can't be zero until B's destructor releases the pointer). Boost also provides a means of dealing with this (weak_ptr), for situations where B really needs to have a shared_ptr to itself.

So, the bottom line of my advice is use shared_ptr (or a similar template class from another library) whenever it makes sense, but be careful, because it's still possible to make yourself leak memory unintentionally. Remember it's ALWAYS possible to leak, and nothing you do can prevent it, but you can minimize how the leaks can happen.