Safe use of "virtual"?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 22/11/2010 at 15:35, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R9+
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;---------
Howdy,I've got a tag that has a public function to set some data, which can be accesses from within the other parts of the plugin by first getting the tag's NodeData and then calling the function from there.
But I'd like to be able to access that function from a different plugin. So, I tried an experiment with a virtual function that seems to work, but I'd like to know if it's safe to do it this way.
Here's some simplified code:
In the tags header file, the class would be defined something like this:
class MyTag : public TagData { public: virtual Bool Init(GeListNode *node); /*.......... */ virtual Bool Message(GeListNode *node, LONG type, void *data); static NodeData *Alloc(void) { return gNew MyStorageTag; } public: void SetValues(Real *data, LONG count); virtual void ExtSetValues(Real *data, LONG count); };The virtual function would then be defined in the plugin's cpp file like this:
void MyTag::ExtSetValues(Real *data, LONG count) { SetValues(Real *data, LONG count); }... so that the virtual function would simply call the public function SetValues() and pass the parameters to it.
Then from a different plugin, it would call the virtual function like this:
MyTag *mTag = static_cast<MyTag*>(tag->GetNodeData()); if(mTag) mTag->ExtSetValues(dataAddress, count);It seems to work OK.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/11/2010 at 01:43, xxxxxxxx wrote:
You don´t need a virtual function for that. It makes no sense here to have it virtual. You don´t even need that function at all. If the public functions are accessible then they are accessible. A virtual function won´t change anything about it. So you could directly call SetValues(). Or why don´t you call SetValues directly? Did you try to do so?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/11/2010 at 06:48, xxxxxxxx wrote:
Howdy,
Yes, the public functions is available, but only from within the same .dylib/.cdl plugin.
But, I'm trying to call that function from within another .dylib/.cdl plugin, and without the virtual function there is a linker error saying that the function is not defined. So, with the virtual function, there is no linker error, and the second plugin can call the function successfully through the virtual function, from outside of the first plugin.
It seems to work. But, I was just curious if it was safe to do, because there is no mention in any C++ reference of using a virtual function this way. Most C++ reference material states that virtual functions are defined in a base class and then overridden in a derived class.
I reckon I could define the SetValues() function in the class declaration in the header file. Then it would be defined when the second plugin includes the header from the first plugin. But at the moment the function is defined in the .cpp file of the other plugin.
Or, I do have another function already in the class that returns a pointer to the data:
Real* GetValues(void) { return values; }... and then just rewrite the "SetValues()" function in the command in the second plugin. This way I wouldn't need to alter the existing first plugin.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/11/2010 at 07:12, xxxxxxxx wrote:
Ah ok, I haven´t seen you were calling it from a different project. Well, in the end a virtual function is just an abstract definition (that´s why there is no linker error) but a static library may be the better way hence why it says it´s not defined though I cannot say anything about safety for the virtual call (also not about thread-safety. Does anybody know? I´d be interested to know what the C++ Standard says about this) as it never occured to me this way. You will know once it´s not working (if I had to guess I´d say it´s fine to use it).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/11/2010 at 08:07, xxxxxxxx wrote:
Howdy,
Well, I decided to go with copying the class function to the second plugin's CommandData class and adding a call to the function that returns the data pointer, simply because then the new plugin will be compatible with other versions of the existing plugin.
But I'd still like to know if the use of a virtual function in that way is safe.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 24/11/2010 at 00:49, xxxxxxxx wrote:
I have been using virtual functions in a similar way, to access functions across the "dll boundary". So far, I have not experienced any problems. (Testing under Windows only).