Interface in CPP?
Author
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.
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.
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.
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.
Quote:Original post by SiCraneOoh, 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...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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
