linuxaudio.org

On Fri, 2011-09-02 at 11:03 -0500, Gabriel Beddingfield wrote:

quoted text
> On Fri, Sep 2, 2011 at 10:22 AM, David Robillard  wrote:

> >> >

> >> > 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?

> >

> > 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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev