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.
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)
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
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 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 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 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 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:
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 299 |
Nodes: | 16 (2 / 14) |
Uptime: | 50:33:25 |
Calls: | 6,689 |
Calls today: | 7 |
Files: | 12,225 |
Messages: | 5,344,596 |
Posted today: | 1 |