Re: u/int64 support for glib, status?
- From: Owen Taylor <otaylor redhat com>
- To: vishnu pobox com
- Cc: Tim Janik <timj gtk org>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: u/int64 support for glib, status?
- Date: 19 Sep 2001 18:42:27 -0400
vishnu pobox com writes:
> On Thu, Sep 20, 2001 at 12:06:16AM +0200, Tim Janik wrote:
> > 1) what should the name be? G_TYPE_INT64 might be a bad choice, what's
> > going to happen for the first 128bit cpu? does it come with long long long,
> > or will the compiler people simply resize long long integer to 128bit?
> > so i'd lean towards something like G_TYPE_BIGUINT and guarantee that
> > it's >= 64bit. though the name is a bit silly ;)
>
> Agreed, the type name should not contain a bit count. After all,
> none of the other fundemental type names contain a bit count.
>
> signed unsigned
> -------- ----------
> quad uquad unintuitive (implies a single is 16 bits)
> bigint biguint fine, but strange to have 'u' in the middle
> bigint ubigint fine
> llong ullong fine -- similar to <limits.h> defines
G_TYPE_INT64 is a fine name.
- 64 bit is what people want, not "the biggest damn numbers the platform
has" If a platform is 64 bit, there is no reason to use slow 128-bit
integers if it has them.
- We have gint64, we don't have gllong, or gquad.
- If we use long long, not a 64 bit integer, we have a risk of making
GValue twice as big if long long is longer than double.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]