Steve Baker originally wrote: > I'd like to use GValues for a lot of parameter storing in > GStreamer but have > just realised that it doesn't store guint64. We use this type > a lot for > storing timestamps. > > Is this an oversight or was it deliberate? GValue does store > a gdouble so > there is already space for a 64 bit type. I haven't had a reply to this yet so I have put together a patch to spur some discussion. The attached patch adds gint64 and guint64 to the types that can be stored directly in a GValue. So the big question is should these types in theory be supported by GValue? I think they should since they add functionality which just isn't there atm. Notes of interest regarding the patch: - every change sits inside a #ifdef G_HAVE_GINT64 - the types are called gint64 and guint64 (I don't know if longlong would be preferred) - value_collect_int64 and value_lcopy_int64 have not been implemented yet (not quite sure what to do here yet) - nothing has been coded yet to support the new types in gvaluetransform.c - I haven't tried building it on a platform which doesn't have 64 bit int support > I guess it would be useful to have g[u]int8/16/32 in there as well. On second thoughts I guess not. 64 bit ints will be useful because they are big, not because they are of a known size. > On a related note, it would be nice if the GValue get/set > functions were > actually implemented as macros. I can't see a reason why they > shouldn't be > and the performance boost would be significantly useful for a > project like > GStreamer. I still think this would be nice but I would be happy to write my own macros to access the GValue struct directly for use within GStreamer. cheers
Attachment:
gint64gvalue.diff
Description: Binary data