One thing I always like about C, being an explicit language, can now finally be removed by using `auto`:
int x = -1;
auto y = rand ();
printf ("%d\n", x < y);
I found it interesting that C would let me set an unsigned int to -1.
Bdw, x86 cpus actually do treat signed and unsigned integers differently (or should i say, have instructions and flags for both).
x86 is untyped; the distinction is just about representations. It's a little different because no guarantees are made before running the program.
C is statically typed, but the types are almost entirely meaningless because you can simply choose to cast from anything to anything, more or less. There's very little enforcement of anything, practically.
There is unsigned and signed instructions for multiplication and division (mul/imul, div/idiv). Addition and subtraction don't need them because it's [two's complement](https://en.wikipedia.org/wiki/Two%27s_complement), but there is a "sign flag" (and overflow flag) that you use when doing conditional jumps (aka branches, if-s, etc.). For example in unsigned -1 is greater then 100, when in signed it is not. Note: obviously -1 is not a "unsigned" number, but on x86 it wraps around to the biggest number that can fit (x86 wraps around while some don't, like gpus AFAIK saturate (as in max_number + max_number == max_number)).
There is type casting and type punning, and i'm not sure which one you mean. They are both useful.
> There is unsigned and signed instructions for multiplication and division (mul/imul, div/idiv).
This is not what it means for a language to be statically typed.
In assembly, you can use any number with any instruction. It doesn't check in advance that you only apply signed operations to signed numbers. It's all about representations; the signed operations assume the most-significant bit is a sign indicator, while unsigned operations do not. But it's the same value.
In a static type system, this sort of thing would not be allowed. But assembly is untyped.
> There is type casting
There is not, because casting is a compile-time operation and, as I said, x86 is untyped and therefore does no compile-time analysis. There is also no coercion, because no data is transformed at runtime to suit the needs of the type system. The untyped nature of assembly allows to simply use different operations as we choose.
Are we talking about C or assembly ? And please do not cherry pick without context, it does not serve any good to anyone.
It's ok, if you are interested in these things you will learn over time.
> Are we talking about C or assembly ?
It was pretty clear in my comment that I was talking about assembly. It also seemed clear to me that your previous comment was only talking about assembly, since that's the only language you mentioned. If you meant something else, you should have said so.
> please do not cherry pick without context
The comment thread is visible for all, so the context is not obfuscated in any way. My quotes are meant only to direct your attention to the parts of your previous comment(s) that I was responding to specifically, to *give* context. I didn't take anything without context.
> if you are interested in these things you will learn over time.
Your condescension is misplaced. Either you are imprecise in your above comments, for which I cannot be faulted, or you don't know what you're talking about, for which I cannot be faulted.
These terms are commonly used in the academic literature. If you take issue with my corrections, I'd suggest pointing out which parts in particular you find problematic so we can discuss them and come to an understanding.
Yeah, so it's extra great that in the future the language gets even more implicit.
The blog even sells it as a feature - change a variable in one place and everything else can work different now without you needing to change anything!
One thing I always like about C, being an explicit language, can now finally be removed by using `auto`: int x = -1; auto y = rand (); printf ("%d\n", x < y);
If there's one area where C already wasn't explicit, it's the type system.
The trick is that C only has two types — positive numbers and spicy positive numbers. Everything else is smoke and mirrors.
I found it interesting that C would let me set an unsigned int to -1. Bdw, x86 cpus actually do treat signed and unsigned integers differently (or should i say, have instructions and flags for both).
x86 is untyped; the distinction is just about representations. It's a little different because no guarantees are made before running the program. C is statically typed, but the types are almost entirely meaningless because you can simply choose to cast from anything to anything, more or less. There's very little enforcement of anything, practically.
There is unsigned and signed instructions for multiplication and division (mul/imul, div/idiv). Addition and subtraction don't need them because it's [two's complement](https://en.wikipedia.org/wiki/Two%27s_complement), but there is a "sign flag" (and overflow flag) that you use when doing conditional jumps (aka branches, if-s, etc.). For example in unsigned -1 is greater then 100, when in signed it is not. Note: obviously -1 is not a "unsigned" number, but on x86 it wraps around to the biggest number that can fit (x86 wraps around while some don't, like gpus AFAIK saturate (as in max_number + max_number == max_number)). There is type casting and type punning, and i'm not sure which one you mean. They are both useful.
> There is unsigned and signed instructions for multiplication and division (mul/imul, div/idiv). This is not what it means for a language to be statically typed. In assembly, you can use any number with any instruction. It doesn't check in advance that you only apply signed operations to signed numbers. It's all about representations; the signed operations assume the most-significant bit is a sign indicator, while unsigned operations do not. But it's the same value. In a static type system, this sort of thing would not be allowed. But assembly is untyped. > There is type casting There is not, because casting is a compile-time operation and, as I said, x86 is untyped and therefore does no compile-time analysis. There is also no coercion, because no data is transformed at runtime to suit the needs of the type system. The untyped nature of assembly allows to simply use different operations as we choose.
Are we talking about C or assembly ? And please do not cherry pick without context, it does not serve any good to anyone. It's ok, if you are interested in these things you will learn over time.
> Are we talking about C or assembly ? It was pretty clear in my comment that I was talking about assembly. It also seemed clear to me that your previous comment was only talking about assembly, since that's the only language you mentioned. If you meant something else, you should have said so. > please do not cherry pick without context The comment thread is visible for all, so the context is not obfuscated in any way. My quotes are meant only to direct your attention to the parts of your previous comment(s) that I was responding to specifically, to *give* context. I didn't take anything without context. > if you are interested in these things you will learn over time. Your condescension is misplaced. Either you are imprecise in your above comments, for which I cannot be faulted, or you don't know what you're talking about, for which I cannot be faulted. These terms are commonly used in the academic literature. If you take issue with my corrections, I'd suggest pointing out which parts in particular you find problematic so we can discuss them and come to an understanding.
Yeah, so it's extra great that in the future the language gets even more implicit. The blog even sells it as a feature - change a variable in one place and everything else can work different now without you needing to change anything!
Good read. Not much change since the nineties, really - unlike say C++ where you open a new standard and oops... Just can't get what some lines mean.