Re: 64 bit nonportability

[Richard Wackerbarth]

On Sat, 03 Jun 2000, Robert Graham Merkel wrote:
> Christopher Browne writes:
>  > What GnuCash probably needs is to _pervasively_ use gint32 rather than
>  > int, gnit32 rather than long, and such.  Of course, someone has to
>  > volunteer to do the global-search-and-replace on this sort of thing...
>
> Before we do that *too* globally, it'd probably be nice to set up
> wrapping these types with g-wrap.
>
> Additionally, for many of the quantities we pass around, might it not
> be a good idea to define a typedef for them, analagous to
> the foo_t types in the C libraries?

I agree. Using gint32 rather than int only solves part of the problem.
foo_t is much more flexible.It reduces the architecture dependency to a 
single point in the code.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Peter C. Norton]

On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> 
> I agree. Using gint32 rather than int only solves part of the problem.
> foo_t is much more flexible.It reduces the architecture dependency to a 
> single point in the code.

How is this different from using already-created typedefs in glib?  glib
seems to provide a lot of the types necessary, already done.

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Dylan Paul Thurston]

On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > I agree. Using gint32 rather than int only solves part of the problem.
> > foo_t is much more flexible.It reduces the architecture dependency to a 
> > single point in the code.
> How is this different from using already-created typedefs in glib?  glib
> seems to provide a lot of the types necessary, already done.

I think the point is that you might decide to change the size of one
of the types at some point.

--Dylan

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Christopher Browne]

On Sat, 03 Jun 2000 22:06:09 PDT, the world broke into rejoicing as
Dylan Paul Thurston <[EMAIL PROTECTED]>  said:
> On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> > On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > > I agree. Using gint32 rather than int only solves part of the problem.
> > > foo_t is much more flexible.It reduces the architecture dependency to a 
> > > single point in the code.
> > How is this different from using already-created typedefs in glib?  glib
> > seems to provide a lot of the types necessary, already done.
> 
> I think the point is that you might decide to change the size of one
> of the types at some point.

Ah, yes.

Basic idea being that it might be good to have a single type, of
platform-independent shape, that GnuCash uses.

Thus, perhaps, the
gcint
type.

Thus, everything in GnuCash would use the gcint type.

gcint is defined via:
  typedef gint32 gcint;

which accordingly references whatever glib.h provides.

Note that this costs us _nothing_ at runtime, as the evaluation of types
is done by the C preprocessor, and this gets expanded, by the compiler, 
to whatever is the "real" type from its perspective.

Mind you, I'm not sure there is _vast_ value in having GnuCash-specific
types over those defined by glib...
--
[EMAIL PROTECTED] - 
"Linux!  Guerrilla UNIX Development Venimus, Vidimus, Dolavimus."
-- <[EMAIL PROTECTED]> Mark A. Horton KA4YBR

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Hendrik Boom]

> On Sat, 03 Jun 2000 22:06:09 PDT, the world broke into rejoicing as
> Dylan Paul Thurston <[EMAIL PROTECTED]>  said:
> > On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote:
> > > On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote:
> > > > I agree. Using gint32 rather than int only solves part of the problem.
> > > > foo_t is much more flexible.It reduces the architecture dependency to a 
> > > > single point in the code.
> > > How is this different from using already-created typedefs in glib?  glib
> > > seems to provide a lot of the types necessary, already done.
> > 
> > I think the point is that you might decide to change the size of one
> > of the types at some point.
> 
> Ah, yes.
> 
> Basic idea being that it might be good to have a single type, of
> platform-independent shape, that GnuCash uses.
> 
> Thus, perhaps, the
> gcint
> type.
> 
> Thus, everything in GnuCash would use the gcint type.
> 
> gcint is defined via:
>   typedef gint32 gcint;
> 
> which accordingly references whatever glib.h provides.
> 
> Note that this costs us _nothing_ at runtime, as the evaluation of types
> is done by the C preprocessor, and this gets expanded, by the compiler, 
> to whatever is the "real" type from its perspective.

I've always had trouble getting constants to have the right type.
I don't think the preprocessor will hanle this cleanly (or have things
changed since I last looked at C?).  Evin if (gint32)7 works (I seem to
remember thst this is not what is technically called a "constant expression"),
there is still trouble with things like getting the maximum integer of type
gint32.

I see

#define G_MININTINT_MIN
#define G_MAXINTINT_MAX

in glibconfig.h, but nowhere do I see a G_MAXINT32.

Or is there something else I need to knw?

-- hendrik.



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: 64 bit nonportability

[Rob Browning]

Hendrik Boom <[EMAIL PROTECTED]> writes:

> #define G_MININT  INT_MIN
> #define G_MAXINT  INT_MAX
> 
> in glibconfig.h, but nowhere do I see a G_MAXINT32.
> 
> Or is there something else I need to knw?

You'd have to define these too if glib didn't.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]