Quote:Original post by SoulSkorpion
The other thing is that I'm fairly sure you're not allowed to make virtual functions inline, and I'm surprised your compiler is letting you get away with it. The two properties are contradictory.
They are not contradictory. You're probably thinking this because you are assuming that all calls to a function declared to be virtual are dynamically bound. This is not the case. Take, for instance, when you are interfacing directly with an object not via a pointer or reference. In these cases, it is impossible to be refering to any type other than the type used in the object's declaration. Therefore, the function can be called just like it were a non-virtual function making it just as fast as a regular function call and very easy to be inlined.
Quote:Original post by Evil Steve
You could try making the function pure virtual, which would probably be a good idea here anyway since you'll never create a cGuiElement, only a derived type.
Yeah. Right now, with the code provided, it looks as though your cGuiElement should be an abstract base class with all pure virtual functions. It seems like it would never make sense to create a cGuiElement and the default virtual function implementations seem arbitrary. You may be better off making them pure virtual functions, and if you really wanted, also provide those semi-blank implementations for the functions as well.
Quote:Original post by Fruny
Secondly, rembember to make cGuiElement's destructor virtual
While I normally would agree, I'm not entirely sure that's necessary here. He never says he has to delete the object through a pointer to the base so I wouldn't make the assumption that it's something he wants. It may just be better to make the destructor protected (or leave it public if he really wantes to keep his cGuiElement as a concrete class, which I wouldn't recommend).
Finally, to the original poster, I do not recommend declaring your class and having only the function implementations in a DLL as you are describing unless you are absolutely positive that is what you want (you may actually just want a static-link library). The reason why I don't recommend it is because one of the primary reasons for using a DLL is that the implementation of objects in the DLL can be changed without affecting client executables. The problem is, since you are only putting the member function implementations in the DLL and are leaving the structure of the type accessable from clients, you are limiting your DLL implementation to the way you originally defined your class. This makes it impossible to update your object's structure -- you can only change the function definitions.
Instead, you would probably be better off making your child classes based off of intermediate classes with all pure virtual functions and have the actual objects allocated in the DLL and manipulated from the client. This way, the implementation of the Gui element can change when the DLL is modified.
If you don't do that and aren't concerned with updating the implementation separate from your client executables, you may just want to use a static link library instead of a DLL (which will also very likely speed up performance as well).
