The Practice of Declaring Custom Classes as Pointers

Hello everyone! I don't know if I asked my question correctly, but this is what I'm after:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class fluffy
{
    public:
    std::string name;
};

class rabbit : public fluffy{};

int main()
{
    fluffy * bunny = new rabbit;
    bunny->name = "Mufasa!";

    /*
       Why not do this:

       fluffy bunny;
       bunny name = "Snuggles";
    */
    return 0;
}


I used to see that quite a lot back when I was learning basic data structures, especially with nodes in linked-lists. But I though I'm past that till I started to encounter this practice when dealing with image wrappers. Could anyone please explain the advantage of using that?
Last edited on
If you want to use polymorphism you need a pointer to the base class. That's the case you have here. rabbit is derived from fluffy, therefore a pointer to a fluffy object can also point to a rabbit object.
http://www.cplusplus.com/doc/tutorial/polymorphism/
In the case of data structures, pointers are used to allow dynamically sized arrays, or in the case of linked lists to refer the nodes to one another.

EDIT: As for your "why not this", it's so that you can call virtually derived functions from the rabbit object. For example, fluffy might have a virtual function "eat", which rabbit overrides. If you just create the fluffy object and call eat, it'll call the fluffy's eat. If you have a fluffy pointer to a rabbit object, it'll instead call the overriden eat function from the rabbit. The link I gave you should be a pretty good explanation of it.
Last edited on
Thank you for your reply. I never really used inheritance and thus polymorphism and these fancy C++ additions because it never was the case that I needed to.

So if I get you correctly: fluffy * bunny = new bunny;, then there's really no reason not to do this instead fluffy bunny;, right?
It depends on if you need polymorphism or not. If you do, then you need to use a pointer to the base class of the derived objects. Otherwise just using a normal object is more efficient.
Hi there,

There is one more consideration for using pointers in datastructures, I think.
It's far more efficient to store pointers in the structure than storing the actual objects, which are usually far larger.

Someone please correct me if I'm wrong here, still learning on the subject myself.

All the best,
NwN
I think I get what you mean, NwN.

Yes, it's more efficient to pass a pointer around rather than a structure. Consider when you pass arguments to functions. If you pass a huge data structure to a function, the function will create a copy of it for it's internal workings. Pointers don't bear this huge overhead - a new pointer may be created but would probably be a lot smaller than the data structure.

At least that's my understanding. Feel free to correct me if I'm wrong.

One other consideration for the OP is where your memory is getting allocated/deallocated (stack or heap).
Polymorphism doesn't require the use of pointers: it works with references in the same manner

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <iostream>
struct fluffy
{
    virtual void eat() const = 0;
    virtual ~fluffy() {};
};

struct hampster : fluffy
{
    void eat() const {
        std::cout << "hampster is eating\n";
    }
};

struct rabbit : fluffy
{
    void eat() const  {
        std::cout << "Rabbit is eating\n";
    }
};

void do_eat(const fluffy& f)
{
    f.eat();
}

int main()
{
    rabbit r;
    hampster h;
    do_eat(r);
    do_eat(h);
}


There are a few reasons to use pointers, but as far as classes and objects go, pointers express aggregation: if object A is keeping track of object(s) B, A holds pointer(s) to B. Hence your linked list usage.

As far as writing code like fluffy * bunny = new rabbit;, it is almost always questionable. The pointer returned by new should always be stored in an appropriate managed pointer type: unique_ptr, shared_ptr, etc.
Last edited on
Topic archived. No new replies allowed.