here is a problem in using 64 big ints on windows ...
On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
Lawrence D'Oliveiro wrote:
On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:maybe but thats not the point
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
On Thu, 04 Apr 2024 03:46:46 +0200, fir wrote:
Lawrence D'Oliveiro wrote:
On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:maybe but thats not the point
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
If you want specific-sized types, that’s the standard C mechanism for providing them.
Lawrence D'Oliveiro wrote:
On Thu, 04 Apr 2024 03:46:46 +0200, fir wrote:ok, but my point is maybe the convention to use that standard ones char
Lawrence D'Oliveiro wrote:
On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:maybe but thats not the point
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
If you want specific-sized types, that’s the standard C mechanism for
providing them.
short int long and allowing them to be set (overwiitting defaults) from
the command line would/wouldnt be just better
someone can think here what they want, but i just wanted to pint that
idea (for eventuall discussion if someone wants)
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Since I remember C had always just defined a '<=' (or '>=') relation between the unsized basic integral data types.
There's several things not quite right about the form of that
sentence, so I'm not quite sure what you meant to say, but C
originally defined the relational operators for any arithmetic type
(and for pointers to compatible object types), including the unsigned
types..
Some complications have been added since then. When extended integer
types and _Bool were added, the definitions were adjusted so that the
integer promotion rules apply to _Bool, and extended integer types are included along with other integer types. When _Complex and _Imaginary
were added, the operands to the relational operators were explicitly
required to be real (which, as C defines the term, includes all
integer types). When decimal floating types were introduced, they
added a prohibition on comparing such values with values that had a
standard floating types. However, nothing matching the restrictions
you imply has ever been true.
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
On Thu, 4 Apr 2024 12:02:16 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
[...]
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Was that the e.g. '*8' syntax? - Did it allow arbitrary lengths?
On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
On Thu, 4 Apr 2024 12:02:16 -0400....
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
On 04.04.2024 19:04, Michael S wrote:....
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Yes, indeed I meant the size of the data types. The comparison
operators of the _values_ of data types wouldn't quite fit on
the topic at all, or so I thought. (Sorry for potentially bad
wording and any possible misinterpretation.)
I thought I've read about those properties at K&R times, that
these properties would hold, but a quick look into some old C
and UNIX books did not show that; only a comment that 'short'
is not larger than 'long'. But I found it in Stroustrup's C++
language book.
Not sure whether that's formally standardized for C.
On 4/4/24 13:04, Michael S wrote:
On Thu, 4 Apr 2024 12:02:16 -0400...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
That's not actually the case. In the above, you are not using <= as the
C operator, but simply to indicate relative order over multiple items; I
will do the same. What is specified is equivalent to the following
LONGLONG_MIN <= LONG_MIN <= INT_MIN <= SHORT_MIN <= SCHAR_MAX
SCHAR_MAX <= SHORT_MAX <= INT_MAX <= LONG_MAX <= LONGLONG_MAX
UCHAR_MAX <= USHORT_MAX <= UINT_MAX <= ULONG_MAX <= ULONGLONG_MAX
SCHAR_MAX <= UCHAR_MAX
INT_MAX <= UINT_MAX
LONG_MAX <= ULONG_MAX
LONGLONG_MAX <= ULONGLONG_MAX
The sizes are not required to be in the same order as the maximum
values, nor in the opposite order of the minimum values. If they were in
a different order, it would imply a lot of padding bits, which would be
very odd, but not prohibited.
On Fri, 5 Apr 2024 02:25:22 +0200, Janis Papanagnou wrote:
On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Was that the e.g. '*8' syntax? - Did it allow arbitrary lengths?
No, and no. Since Fortran 2003, [...]
you can parameterize a custom type
definition with integer values. These can be used to specify the sizes of arrays, or they can be used as codes for the different (implementation- defined) precisions of integer and real types. An example from the
language spec:
TYPE :: t1(k1,k2)
INTEGER, KIND :: k1,k2
REAL(k1) a(k2)
END TYPE
This defines a custom type “t1”, which is an array of reals; the first parameter determines the precision of the reals, and the second one specifies the length of the array.
There are various query mechanisms (built-in functions, standard modules)
to determine the valid values of the number-precision codes.
For the first question I thought you were referring to old Fortran
versions ...
Yes, but I read that 'KIND' specification as a readable variant of the
old syntax ...
On Fri, 5 Apr 2024 08:30:16 +0200, Janis Papanagnou wrote:on
=20
For the first question I thought you were referring to old Fortran=20
versions ... =20
I did say =E2=80=9Chas=E2=80=9D, not =E2=80=9Chad=E2=80=9D.
=20
Yes, but I read that 'KIND' specification as a readable variant of=20
the old syntax ... =20
It=E2=80=99s parameterizable. That means it is easy to change the precisi=
of the type right through your code just by altering one definition.
=20
Also, KIND participates in function overloading. That requires it to
be compile-time constant. There are also LEN parameters, which can be=20 dynamic, but can only be used to size arrays and strings.
On Fri, 5 Apr 2024 07:18:09 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 5 Apr 2024 08:30:16 +0200, Janis Papanagnou wrote:
For the first question I thought you were referring to old Fortran
versions ...
I did say “has”, not “had”.
Yes, but I read that 'KIND' specification as a readable variant of
the old syntax ...
It’s parameterizable. That means it is easy to change the precision
of the type right through your code just by altering one definition.
Also, KIND participates in function overloading. That requires it to
be compile-time constant. There are also LEN parameters, which can be
dynamic, but can only be used to size arrays and strings.
I still think that Janis asked correct questions and that you answered misleading answers.
I had never read the Fortran-2003 Standard, however I will be very
surprised if it mandates support for integer types wider than 64 bits
(or 18 decimal digits). I would not be surprised if hard mandate is
even lower, may be only 9 digits.
Also I would be surprised if there are implementations that support
integers that are wider than 128 bits (38 digits).
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 7 |
Nodes: | 8 (0 / 8) |
Uptime: | 123:03:29 |
Calls: | 46 |
Files: | 21,492 |
Messages: | 64,818 |