Function pointer question.

[rabster]

Is it a bad thing to make a function pointer? I remember reading up somewhere it was. I'm asking this because let's say we have a class with pure virtual functions and I want to be able to return that classes info. Since it has pure virtual functions I can't make it a normal class instance, rather I would have to make it a pointer function. I'm asking this because I have a loot class which will randomly make loot for the armor class and well the only way I will be able to return the armor made from the loot class would be if I make it a function pointer. Another way would be to remove all pure virtual functions, although not sure I want to do that.

[TarikNeaj]

Please don't double post - http://www.cplusplus.com/forum/general/184370/

(Might have been unintentional)

Edit: Yeh, that problem has happened to me too, dont worry about it =)

[rabster]

Yeah it was, the site gave me an error and I thought it didn't post so I posted it again. When I checked there was no post so yeah like I said. Can you delete a post or no? Anyways the question for this post still stands.

EDIT: I deleted it.

[helios]

What you're describing is not a function pointer (i.e. a pointer that points to a function), but a function that returns a pointer.
No, there's nothing wrong with a create() member function that constructs an instance of a derived class and returns a pointer to it. Returning a smart pointer instead of a naked pointer would be better, though.

[rabster]

Thanks for informing me. Also I know how the syntax for a smart but I just don't when to use them? I know they control the scope of the pointer that was allocated on the heap but why would I ever need that? Ain't one of the benefits of a pointer allocated with new is so that I can control it's scope.

[helios]

More accurately, the benefit of a dynamically allocated object is that its lifetime is not bound to the scope which created it, unlike an object with automatic storage. Additionally, polymorphism only makes sense with pointers.
The problem with using naked pointers is that the code becomes more brittle. For example, imagine that you call Base::create() in a constructor:

class SomeClass{
    Base *base;
public:
    SomeClass(){
        this->base = Base::create();
        some_function();
    }
    ~SomeClass(){
        delete this->base;
    }
};

If some_function() throws an exception, the pointer returned by Base::create() will be leaked, because SomeClass::~SomeClass() will not be called. If, however, you do this:

class SomeClass{
    std::unique_ptr<Base> base;
public:
    SomeClass(){
        this->base = Base::create();
        some_function();
    }
};

The pointer will be freed no matter what.

[rabster]

That is pretty neat, I guess smart pointers are pretty nice. I'll be sure to try and implement them. Also why won't ~Someclass() be called if an exception occurs in another function? Couldn't you catch the exception also, won't the destructor be called at the end of it's life time anyways? Or if its deleted? I was reading up somewhere that raw pointers are better in performance as well, unless that doesn't really matter and its very minor?

[cire]

Also why won't ~Someclass() be called if an exception occurs in another function?

The specific case described here is when a function which is called in the constructor of SomeClass throws. In that situation, the constructor has not completed and the object is not considered to exist yet so the destructor will not be called. If this happened in any non-constructor method, it wouldn't be an issue.

[rabster]

Ah okay@cire I understand, anyways thanks guys for all the information!