It depends.
If your surface is intended as an extension of SDL_Surface, and must participate in all operation / functions SDL_Surface is involved into, you will probably like to have a way to expose the "basic" element.
But, instead of returning a pointer from a class (something that has a different indirection level in expressions), you would probably had better to return a reference or a cost-reference or both:
class Surface
{
public:
operator SDL_Surface& () { return *surf_; }
operator const SDL_Surface& () const { return *surf_; }
private:
SDL_Surface* surf_;
}
(Note: avoid that C#-ish Javanese this->xxxx
style...)
If your Surface is just another thing, that needs an SDL_Surface to work with, bat has all another application domain, than no implicit conversions should be available.
NOTE:
In the above note I'm not doing any assumption about Surface and SDL_Surface lifetime or ownership.
I just assume both object exist whenever they have to participate in whatever operation. Who creates and destroys them an in which order and when, is all another story.
Note that the usage of reference counting smart pointer don't solve the general problem: until you don't define an ownership direction, forgetting about pointers in favor of shared_ptr
is just a good way to make memory leaks because of circular reference.
A very very common mistake, especially from Java programmers.
Moral of the story: be sure of what you want to do with those objects, before decide how create and delete them, witch king of "pointer" to use to hold them and if enable or not implicit conversions and which.