On 2013-06-11 19:48, captaindet wrote:
On 2013-06-11 07:35, Adam D. Ruppe wrote:
On Tuesday, 11 June 2013 at 10:12:27 UTC, Temtaime wrote:
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly
convert expression (cast(int)k + 1) of type int to ubyte
T
On Tue, 11 Jun 2013 20:58:17 -0400, Ali Çehreli wrote:
On 06/11/2013 05:48 PM, captaindet wrote:
> i think part of the problem is that '1' is an int. so the calculation
> must be promoted to integer.
No, the compiler knows that 1 could fit in a ubyte. It has
value-range-propagation. Ch
On Wednesday, 12 June 2013 at 01:35:47 UTC, Adam D. Ruppe wrote:
// byte multiplication, answer goes into a 16 bit register,
but we could truncate it too
BTW just as a personal note you might be amused by, this multiply
instruction beat the crap out of me when I was learning x86
assembly ba
On Wednesday, 12 June 2013 at 00:58:17 UTC, Ali Çehreli wrote:
The CPU would have to have special registers to do those
operations in. (I am under the impression that x86 does not
have any arithmetic registers for types narrower than int.)
It does, for 8, 16, 32, and 64 bits. Here's how 8 and
On 06/11/2013 05:48 PM, captaindet wrote:
> i think part of the problem is that '1' is an int. so the calculation
> must be promoted to integer.
According to "Integer Promotions" and "Usual Arithmetic Conversions"
there is no arithmetic operation that is executed in any type narrower
than int:
On 2013-06-11 07:35, Adam D. Ruppe wrote:
On Tuesday, 11 June 2013 at 10:12:27 UTC, Temtaime wrote:
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly
convert expression (cast(int)k + 1) of type int to ubyte
The reason is arithmetic operations trans
On Tuesday, 11 June 2013 at 19:09:11 UTC, Timothee Cour wrote:
wouldn't it be a better and more consistent idea to implement
bearophile's 'Compiler support to implement efficient safe
integrals'
http://d.puremagic.com/issues/show_bug.cgi?id=9850 so uint/int
etc would require no cast
This isn'
On Tue, Jun 11, 2013 at 11:26 AM, H. S. Teoh wrote:
> On Tue, Jun 11, 2013 at 01:25:24PM -0400, Steven Schveighoffer wrote:
> > On Tue, 11 Jun 2013 12:18:52 -0400, Adam D. Ruppe
> > wrote:
> >
> > >On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer wrote:
> > >>CPU performs math at i
On Tue, Jun 11, 2013 at 01:25:24PM -0400, Steven Schveighoffer wrote:
> On Tue, 11 Jun 2013 12:18:52 -0400, Adam D. Ruppe
> wrote:
>
> >On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer wrote:
> >>CPU performs math at int level.
> >
> >eh, I wouldn't blame the hardware. You can do
>
On Tue, 11 Jun 2013 12:18:52 -0400, Adam D. Ruppe
wrote:
On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer wrote:
CPU performs math at int level.
eh, I wouldn't blame the hardware. You can do
asm {
mov AL, 10;
add AL, 5;
}
and it is allowed, it also don't spill into AH
On Tuesday, 11 June 2013 at 16:18:54 UTC, Adam D. Ruppe wrote:
I'd be extremely annoyed if that required a cast. It's bleeding
obvious that you want it to assign back there
To me u = u + k is as obvious as u += k, but that's probably not
a thing anyone would be much concerned about :)
On Tuesday, 11 June 2013 at 16:05:30 UTC, Steven Schveighoffer
wrote:
CPU performs math at int level.
eh, I wouldn't blame the hardware. You can do
asm {
mov AL, 10;
add AL, 5;
}
and it is allowed, it also don't spill into AH if you overflow it
(it just sets the carry flag). I'm sure it
On Tue, 11 Jun 2013 07:46:11 -0400, Temtaime wrote:
No. I means, that
uint a = uint.max;
uint b = a + 1;
writeln(b);
Works OK.
Why? Compiler doesn't know if a + b fits in uint, right?
Then why overflow with ints are accepted?
CPU performs math at int level. So even if you add two ubytes, t
On Tuesday, 11 June 2013 at 10:12:27 UTC, Temtaime wrote:
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly
convert expression (cast(int)k + 1) of type int to ubyte
The reason is arithmetic operations transform the operands into
ints, that's why t
Temtaime:
Why? Compiler doesn't know if a + b fits in uint, right?
Then why overflow with ints are accepted?
It's an inconstancy based on practical considerations.
Walter decided that applying the same rule to uint/int/long
causes too many casts in normal problems.
And the range of a 32 bi
On Tue, 11 Jun 2013 13:46:11 +0200, Temtaime wrote:
No. I means, that
uint a = uint.max;
uint b = a + 1;
writeln(b);
Works OK.
Why? Compiler doesn't know if a + b fits in uint, right?
Then why overflow with ints are accepted?
Because there's a limit to how far this goes without introducing
No. I means, that
uint a = uint.max;
uint b = a + 1;
writeln(b);
Works OK.
Why? Compiler doesn't know if a + b fits in uint, right?
Then why overflow with ints are accepted?
So your example is meaningless.
On Tue, 11 Jun 2013 13:15:11 +0200, Simen Kjaeraas
wrote:
On Tue, 11 Jun 2013 12:39:47 +0200, Temtaime wrote:
There is overflow and it can be with int too.
It's standard behavior.
Indeed. And a class is a void* is an int is a char is a double? That's
perfectly possible - it's all just me
Temtaime:
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly
convert expression (cast(int)k + 1) of type int to ubyte
Why? It's pain in the ass, i think. My code contains only casts
then.
I agree that sometimes that's a pain.
Currently D perform
On Tue, 11 Jun 2013 12:39:47 +0200, Temtaime wrote:
There is overflow and it can be with int too.
It's standard behavior.
Indeed. And a class is a void* is an int is a char is a double? That's
perfectly possible - it's all just memory anyway. D has chosen to do
it like this to prevent common
There is overflow and it can be with int too.
It's standard behavior.
On Tue, 11 Jun 2013 12:12:25 +0200, Temtaime wrote:
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly convert
expression (cast(int)k + 1) of type int to ubyte
Why? It's pain in the ass, i think. My code contains only casts then.
Because it's u
ubyte k = 10;
ubyte c = k + 1;
This code fails to compile because of: Error: cannot implicitly
convert expression (cast(int)k + 1) of type int to ubyte
Why? It's pain in the ass, i think. My code contains only casts
then.
23 matches
Mail list logo
