richard_damon wrote on Monday, September 05, 2011:
You may have misunderstood me. A plain pointer IS a POD, so can be sent. What can’t be put in are *objects* that are’t PODs, which include most (all?) “smart pointer classes”.
Yes, in an object that qualifies for RTTI (having a virtual function, which polymorphic classes tend to have), imbedded in the data for the object will be a VPtr, which is a pointer to a compiler built structure called the VTable (or it sounds like in your sources the VMT). (Object with multiple or virtual bases may end up with multiple VPtrs in them). If the most base class was RTTI eligible, then the VPTR tends to be the first element in the object as it is most likely the most used element of the object. Any call to a virtual method will go via this VPtr and VTable
Note, you can not create a “fixed array” of varying types, so I don’t think that is actually going to be a solution.
If you make the heap protected (for example, getting new to call pvPortMalloc instead of malloc directly) then task A could just create a new object with new, pass the pointer via a queue to task B, and then task B could delete the object. This may be the “simplest” option, assuming you can make new/delete safe and can tolerate the issues of using a heap in a “real time” program.
Another option is to create pools of the various object that need to be sent, and task A “checks out” an object from the appropriate pool, and when task B is done, it checks it back in (probably via a member function of the object, as it should know which pool it came from).