Sujet : Re: remark on defining size of basic types
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 04. Apr 2024, 14:15:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uum95f$lr8o$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 04.04.2024 13:32, fir wrote:
Lawrence D'Oliveiro wrote:
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:
>
here is a problem in using 64 big ints on windows ...
>
#include <stdint.h>
>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
>
maybe but thats not the point
>
If you want specific-sized types, that’s the standard C mechanism for
providing them.
>
ok, but my point is maybe the convention to use that standard ones char
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)
*If* the size matters you should/could use the sized data types that
you see above. If size doesn't matter, why redefine the basic types?
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
You may want to explain what (positive) effect you expect from such
a language change or feature. (And consider what drawbacks and issues
would be accompanied with it.)
Sometimes it's useful to have an unbounded or parameterized integral
data type available - this is what I initially thought your thread
might be about - and some language (not C) do support that.
Janis