I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
The unfortunate answer is that C/C++ is just
plain ill considered. The argument that you
should just use cout is
On 05/19/2010 08:25 AM, John Plevyak wrote:
I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
Agreed.
Think that Leif is working on 64-bit file API, and
forcing that
On 05/19/2010 04:17 AM, Mladen Turk wrote:
On 05/19/2010 08:25 AM, John Plevyak wrote:
I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
Agreed.
Think that Leif is
I propose that we change
ink64 - int64
inku64 - uint64
ink32 - int32
inku32 - uint32
ink16 - int16
inku16 - uint16
ink8 - int8
inku8 - uint8
because
1) we decided to move from ink - ts
2) tsu64 doesn't scan like an integer
3) int64_t is long on linux which is incompatible with %lld the
in int64 etc from some standard (ANSI / POSIX include file)? My stdint.h
only has the int64_t etc. definitions.
Also, if we do this, shouldn't we also change
#define INKU64_MAX (18446744073709551615ULL)
#define INK64_MAX (9223372036854775807LL)
#define INK64_MIN (-INK64_MAX -1LL)
#define
some standard (ANSI / POSIX include file)? My stdint.h
only has the int64_t etc. definitions.
Also, if we do this, shouldn't we also change
#define INKU64_MAX (18446744073709551615ULL)
#define INK64_MAX (9223372036854775807LL)
#define INK64_MIN (-INK64_MAX -1LL)
#define INKU32_MAX
/write a
64-bit number
4) int64 is similar but not the same as ink64_t and it scans well
5) I tried it and it works!
Would this be a name change only (in our ink_port.h file)? Or do we pull
in int64 etc from some standard (ANSI / POSIX include file)? My stdint.h
only has the int64_t etc
On 05/19/2010 10:31 AM, Bryan Call wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
typedef
ink_port.h file)? Or do we pull
in int64 etc from some standard (ANSI / POSIX include file)? My stdint.h
only has the int64_t etc. definitions.
Also, if we do this, shouldn't we also change
#define INKU64_MAX (18446744073709551615ULL)
#define INK64_MAX (9223372036854775807LL)
#define INK64_MIN
+1
Wednesday, May 19, 2010, 11:31:50 AM, you wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
Late but
+1
-George
On 5/19/10 9:57 AM, Leif Hedstrom wrote:
On 05/19/2010 10:31 AM, Bryan Call wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
It seems that g++/C++ is completely broken with respect to portable
64-bit numbers and scanf/printf.
uint64_t is long long int on 32-bit machines and long int on 64-bit
machines and scanf/printf require the corresponding %lld %ld which is
painfully difficult.
Until they fix it, either we use
On 05/19/2010 02:52 AM, John Plevyak wrote:
Why the hell uint64_t is defined this way and g++ complains even
though long int == long long it is beyond me.
Suggestions, comments?
I saw whole bunch of %ld, %lld stuff in the code which will IMHO
never be portable no matter what type you use.
There are standard macros for doing that (e.g. PRIu64) which are defined
in /usr/include/inttypes.h for ISO C99 7.8.
If we had to go that route I would go with those rather than a
roll-your-own even if that means defining them on platforms that
don't have ISC C99 support yet (only a decade
On 05/19/2010 06:35 AM, John Plevyak wrote:
However, since the C99 and new C++ standard declares that long long int
is 64-bit and since just about everyone already has that:
linux, solaris, freebsd, mac, and since I have been able to use it
portably for several years now I would rather go that
All compilers that are C99 compliant must accept
%lld as long long int where sizeof(long long int) == 8.
Sun 64 and linux 64 both have sizeof(long) == 8, but
because of C99 they also have sizeof(long long int) == 8
and %ld and %lld will both work with 64-bit arguments,
however gcc/g++ will
On 05/19/2010 07:02 AM, John Plevyak wrote:
I would say that if we can't find a system which doesn't
support the standard %lld for 64-bit numbers then we should
just go with the standard. It is simpler and it will only
be more right as time passes because it is the standard.
Fair enough.
17 matches
Mail list logo
