Dave Robillard wrote:
>> Not valid in C++.
> Ah, that was it. Back to char we go.
We have some choices:
1. your original uint8_t - good because you can still do
(&event->data)[offset], bad because it breaks sizeof somewhat, making it
totally misleading (this particular clock doesn't show the right time
even once per 12 hours ;) )
2. uint8_t[1] - variant of solution 1, just *slightly* better because
you can write event->data[offset] instead of (&event->data)[offset]
3. uint8_t[0] - gcc extension, possibly incompatible with non-gcc
compilers (I don't care, I bet someone else does)
4. uint8_t[4] - variant of solution 1 with somewhat better sizeof
behaviour (at least it returns the proper size for payload length <= 4)
5. separate "header structure" and event-type specific "event structure"
(with header as first field), equivalent to what Nedko proposed. Not as
awkward as you probably imagine. You'll find examples in my previous
mails if you have any doubt about what I mean.
I'm fine with either choice. 4 and 5 look somewhat attractive, 3 is
probably out of the question.
Anyway, we're arguing about changing one or two lines of code in a
plugin here, so if you think a single uint8_t member is a way to go,
it's fine IMHO.
The URI passing thing is much more interesting, as it affects 5 lines of
plugin code, not 2, so it'd be better to concentrate on that one.
I'd still prefer to have new URI mappings delivered to plugins (which
you don't like), and URI-int mapping to be implemented in a host (which
you like, IIRC). No matter what calling convention is - "C++-style"
object or a structure with function pointer and instance pointer. At
least as long as it doesn't lead to GObject-style insanity :)
> this struct in that case would be handy), but I guess that could just be
> another event type?
Absolutely.
> char* does cause confusion though, as this thread made painfully clear
> earlier...
Yes, and how would you refer to in-place char data? ((char
*)(&event->data))[0]? Do you like it?
Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Dec 10 16:15:01 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 10 2007 - 16:15:01 EET