non-64bit platforms? (Re: g[u]int64 GValues (was GValue questions))

[Tim Janik <timj gtk org>]

On Fri, 27 Jul 2001, Steve Baker wrote:

> Steve Baker originally wrote:

> > 
> > Is this an oversight or was it deliberate? GValue does store 
> > a gdouble so
> > there is already space for a 64 bit type.

right, but afaik, 64bit ints are not supported on all system/compiler versions
that glob runs on. at least historically this has been an issue, which is why
we special-case guint64 definitions in glib based on a configure.in check.
i'm not quite sure where 64bit ints fail nowadays though, irrc, orbit
has a hard dependancy on 64bit ints for quite some time now and runs on a 
bunch of systems.
so my current attitude towards this is:

1) if we don't need to special case int64 in glib anymore since every system
   that we care about now supports it, we should always provide gint64 defs.
2) once we unconditionally support >32bit integers, we should have GType support
   for it (probably G_TYPE_BIG_INT or something and just guarrantee its >=64 bit).


i'd apprechiate comments from people, if thee are any,  that run glib on
platforms/compilers that do not have 64bit ints.


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

i've been sick for some time, so couldn't reply earlier.
i do have a gint64 implementation ready already though since BEAST/BSE needs
it for timestamps as well ;)

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

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

you should _never_ access GValue fields directly, except if implementing a
fundamental type. storage algorithms may change even during stable releases,
the only reason for us to export the structure contents is
1) to allow GValues to be allocated on the stack (though we could even use
   cruel padding hacks here)
2) to allow people to implement new fundamental types

but don't access GValue fields of existing fundamental types, that'll just
guarrantee you breakage of your program with future versions of glib.

> 
> cheers
> 

---
ciaoTJ