1 Dec
2007
1 Dec
'07
3:19 p.m.
On Sat, 2007-12-01 at 14:09 -0500, Dave Robillard wrote:
On Fri, 2007-11-30 at 16:21 +0200, Nedko Arnaudov
wrote:
Agreed. Most plugins won't care about the fractional part. The only
drawback I can think of is that on a platform that aligns struct members
to 32 bits you won't be able to load the complete timestamp as a
uint32_t without some shifting and |ing, but that will probably be a
special case anyway. Having the timestamp as two separate members makes
everything completely self-documented.
Krzysztof Foltman <wdev(a)foltman.com>
writes:
> Lars Luthman wrote:
>
>> non-standard hacks in a specification. But with the current event header
>> proposal we don't have a pointer _or_ a flexible array member in it, so
>> this discussion is sort of pointless.
>
> So, basically, we have a choice between:
>
> struct LV2_EVENT_HEADER_LLKF
> {
> uint32_t timestamp; // 16:16
> uint16_t payload_size;
> uint16_t event_type;
> };
Might as well break the time stamp into two separate uint16_t's and make
life easy. Please, please let this silly 'type of the data
member' angle of
conversation die... :)
Hereby humbly requesting that:
// data follows here
be the last thing in the event struct for the purposes of this
conversation, since it's irrelevant and not a point of debate
Agreed.
--ll