2 Sep
2011
2 Sep
'11
6:03 p.m.
On Fri, Sep 2, 2011 at 10:22 AM, David Robillard <d(a)drobilla.net> wrote:
Because it uses inheritance, this object is not POD, so strictly
speaking no.
Yes, it's not strictly POD. However, the objective was to have an
RT-safe way to pass almost-POD objects in the confines of a
single-process, shared-memory application. In this situation, I think
the the fact that the vtable is not POD is a non-issue because the
pointers are all valid, static references.
However, if he needs some manner of IPC, serialization, or plugin
(loading/unloading code) scheme... then this is indeed a show stopper.
-gabriel
The main issue you'll find with going the C++/RTTI route is that #2 no
longer is possible, since virtual objects are not POD, so you can't
safely write them through a ringbuffer (or copy them around manually in
general).
[snip]
Correct me if I'm wrong... but...
> class event_two_t : public event_t
> {
> public:
> int type() { return int(EVENT_TWO); }
> uint32_t size() { return sizeof(event_two); }
>
> /* event-specific stuff */
> };
The intention of the size() member function is to allow you to memcpy()
the object without knowing its type. Is that not enough?