Re: 64 bit nonportability
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]
Re: 64 bit nonportability
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
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
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
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
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] - http://www.ntlug.org/~cbbrowne/ "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]
