g[u]int64 GValues (was GValue questions)



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]