2 Sep
2011
2 Sep
'11
6:29 p.m.
On Fri, 2011-09-02 at 11:03 -0500, Gabriel Beddingfield wrote:
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.
You may be able to get away with it depending on your compiler
implementation/system/phase of the moon, but since in this particular
example you're just dispatching by type anyway and gaining nothing from
using inheritance, it'd be a bit silly to do so...
This may be a hand-wavey justification, but I have seen some pretty
weird stuff happen when I treated not-strictly but pretty-much-POD
objects as POD data. Weird stuff like things working fine 99% of the
time but catastrophically exploding occasionally. Given that this is
explicitly illegal (i.e. that you don't do this is an assumption the
compiler makes), and aggressive optimization is in use, this isn't too
surprising. It's best not to tread in that dark valley, C++ is awful
enough when you follow the rules :)
-dr
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?