• Advertisement
Sign in to follow this  

Interface in CPP?

This topic is 4224 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have created a SpriteDrawer class which uses direct3D vertex. Now I want to change the implementation and use D3DXSprite instead. However, I dont want to change the SpriteDrawer interface and I also want to save the older implementation. Should I make SpriteDrawer like an interface? making all its methods pure virtual and then change the older implementation into VertexSpriteDrawer? Also, my primary question is, should I make the dtr of SpriteDrawer also pure virtual? the ctr? I also have a private cpy ctr in SpriteDrawer to prevent passing it by value. What shoul I do with the cpy ctr? Should I make it pure virtual as well? or if I will keep it as a regular method it will prevent also its children classes from being able to be passed by value? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
If you create any class with one or more pure virtual functions in it, the compiler won't let you create an instance of the class, so you won't be able to pass it around by value.
If you have any virtual functions, you should usually have a virtual destructor. It can't be pure virtual, but it can be empty. And you can't have a virtual constructor (pure or not). Just an empty default constructor would do.

Perosnally, I wouldn't bother making it an interface. You shouldbe able to change the class itself without changing the member function names and parameters if the class is designed well. The only advantages of making it an interface would be you could implement it in a DLL, and you could create a child class ta runtime to implement the interface.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
It can't be pure virtual, but it can be empty. And you can't have a virtual constructor (pure or not).

Destructors can be pure virtual.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by Evil Steve
It can't be pure virtual, but it can be empty. And you can't have a virtual constructor (pure or not).

Destructors can be pure virtual.
Ooh, I didn't know that... What would be the point in that? It'd just force you to implement a destructor, even if it was empty...

Share this post


Link to post
Share on other sites
Yep, even if you have a pure virtual destructor, you still need to provide an implementation of it (usually empty) to avoid link errors.

This can be used to make a class abstract, whilst providing default implementations of all functions, however I've never come across an instance where this would be useful.

Share this post


Link to post
Share on other sites
With a pure virtual destructor you can make a class abstract without specifying any other pure virtual functions. It also serves as a very strong indication to the compiler that the destructor shouldn't be inlined, which can reduce errors in the case of improperly exported data members in DLLs.

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
I have created a SpriteDrawer class which uses direct3D vertex.
Now I want to change the implementation and use D3DXSprite instead.
However, I dont want to change the SpriteDrawer interface and I also want to save the older implementation.
Should I make SpriteDrawer like an interface? making all its methods pure virtual and then change the older implementation into VertexSpriteDrawer?
Also, my primary question is, should I make the dtr of SpriteDrawer also pure virtual? the ctr? I also have a private cpy ctr in SpriteDrawer to prevent passing it by value. What shoul I do with the cpy ctr? Should I make it pure virtual as well? or if I will keep it as a regular method it will prevent also its children classes from being able to be passed by value?

Thanks in advance.


Do you want to use either implimentation without the client code knowing which? If yes then it needs to be polymorphic and you'll need to define an abstract base class which defines the interface.
Since it it polymorphic, you need to declare each interface function to be virtual, including the destructor.
The base class won't actually implement anything, so you should probably make its functions pure.
A virtual constructor doesn't make sence, because you need to know what type of object you're creating when you create it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement