On Tuesday, 11 December 2012 at 12:53:38 UTC, monarch_dodra wrote:
integer operations are always promoted to at least int. That's
standard fare since C. I think it is a performance thing:
Unpack into ints, oeprate, repack into ints.
If memory serves me right, promotion to int is based more
On 12/13/2012 10:19 PM, H. S. Teoh wrote:
This is cool, I've never thought of using alias this on a @property
function. I'll have to start using that in my code. :-)
That's actually why I wrote it - as a template for how to do similar user
defined types.
The rest of the code is tl;dr, but
On Fri, Dec 14, 2012 at 12:39:04AM -0800, Walter Bright wrote:
On 12/13/2012 10:19 PM, H. S. Teoh wrote:
This is cool, I've never thought of using alias this on a @property
function. I'll have to start using that in my code. :-)
That's actually why I wrote it - as a template for how to do
On 12/14/2012 4:02 PM, H. S. Teoh wrote:
I'm so impressed by this trick that I decided to do a writeup of it on
the wiki:
http://wiki.dlang.org/Implicit_conversions_in_user_types
I'd prefer to call it a technique rather than a trick, because this is what
alias this was designed for!
On Saturday, 15 December 2012 at 02:23:18 UTC, Walter Bright
wrote:
I'd prefer to call it a technique rather than a trick,
because this is what alias this was designed for!
BTW is there any idea for the timetable of multiple alas this
like described in Andrei's book?
On 12/14/2012 6:27 PM, Adam D. Ruppe wrote:
BTW is there any idea for the timetable of multiple alas this like described in
Andrei's book?
Not at the moment.
On 2012-22-13 04:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
If alias this isn't do an implict conversion, then there's a bug in
alias
this. That's how implict conversion is
D does not support such implicit *construction* in return statement and
function argument.
It is a current language design, and not a bug.
Kenji Hara
2012/12/13 Simen Kjaeraas simen.kja...@gmail.com
On 2012-22-13 04:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, December 12,
On 12/13/2012 6:30 AM, Simen Kjaeraas wrote:
Walter does not seem to agree (see his post in this discussion).
Note that the following implementation of halffloat does work, allowing explicit
cast to halffloat and implicit conversion from.
(The halffloat literals don't work at the moment
On Thu, Dec 13, 2012 at 05:44:23PM -0800, Walter Bright wrote:
On 12/13/2012 6:30 AM, Simen Kjaeraas wrote:
Walter does not seem to agree (see his post in this discussion).
Note that the following implementation of halffloat does work,
allowing explicit cast to halffloat and implicit
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the computation and
assignment but then returns a bbyte instead of an int.
You should have no problems implicitly converting
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the computation and
assignment but then returns a
On 2012-17-12 10:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts
On Wednesday, 12 December 2012 at 08:23:48 UTC, Simen Kjaeraas
wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the
computation and assignment but then returns a bbyte
On Wednesday, December 12, 2012 10:42:31 Simen Kjaeraas wrote:
Really? This certainly does not compile for me:
struct bbyte {
byte b;
alias b this;
}
void bar(bbyte b) {}
bbyte baz() {
byte b;
return b; // cannot implicitly convert expression (b) of type byte to
bbyte
}
void
On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
If alias this isn't do an implict conversion, then there's a bug in alias
this. That's how implict conversion is done in D, and it's the whole point
of alias this.
And it does, as I relied on this to do the halffloat implementation.
On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
If alias this isn't do an implict conversion, then there's a bug in alias
this. That's how implict conversion is done in D, and it's the whole point
of alias this.
And it does,
Greetings
The following code prints . Similar thing happens when a and b are
bytes.
Is this intended?
Regards
- Puneet
void main()
{
import std.stdio;
ushort a = 0x55AA;
ushort b = 0xAA55;
writefln(%X, ~(a | b));
}
For some more clarity, when I compile the following code:
void main() {
import std.stdio;
byte a;
byte b;
byte c = a + b;
}
I get error:
test.d(6): Error: cannot implicitly convert expression (cast(int)a +
cast(int)b) of type int to byte
Why is D trying to convert bytes and shorts to
On Tuesday, 11 December 2012 at 12:24:14 UTC, d coder wrote:
Greetings
The following code prints . Similar thing happens when
a and b are
bytes.
Is this intended?
Regards
- Puneet
void main()
{
import std.stdio;
ushort a = 0x55AA;
ushort b = 0xAA55;
writefln(%X, ~(a | b));
}
On Tuesday, 11 December 2012 at 12:30:35 UTC, d coder wrote:
For some more clarity, when I compile the following code:
void main() {
import std.stdio;
byte a;
byte b;
byte c = a + b;
}
I get error:
test.d(6): Error: cannot implicitly convert expression
(cast(int)a +
cast(int)b) of
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra monarchdo...@gmail.comwrote:
D's stance regarding integer operations is if it compiles, it creates the
same output as in C.
Thanks Monarch. So it is a gotcha we inherit from C. :-)
Regards
- Puneet
On 12/11/12 8:03 AM, d coder wrote:
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra monarchdo...@gmail.com
mailto:monarchdo...@gmail.com wrote:
D's stance regarding integer operations is if it compiles, it
creates the same output as in C.
Thanks Monarch. So it is a gotcha we inherit
On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
That's the whole point. What you are doing is dangerous, so it
requires the cast.
Adding a compiler flag to change the semantics of the
On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander
peter.alexander...@gmail.com wrote:
That's the whole point. What you are doing is dangerous, so it requires
the cast.
What I am doing is not dangerous. I am operating at byte/short level.
Tell me, if what I am doing is dangerous, how come
d coder:
Tell me, if what I am doing is dangerous, how come doing the
following is not dangerous. It is allowed by D.
int a, b, c;
a = b + c;
I think this dis-uniformity was added because:
- Statistically it's more common to have an overflow when you sum
two bytes compared to summing two
On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just allow
the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
Well I know the advantages (safety). But imagine
On 12/11/12 8:24 AM, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just allow the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
Well I know the advantages (safety). But imagine having to write all
Thanks Everybody for responding. I have another query which is off-topic
but related.
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a; // Not allowed
d coder:
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a; // Not allowed
Seems a bug of range analysis.
Bye,
bearophile
On 12/11/12 11:36 AM, d coder wrote:
Thanks Everybody for responding. I have another query which is off-topic
but related.
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
RMW operations are allowed without a cast.
Andrei
On 12/11/2012 5:24 AM, d coder wrote:
Would I be asking for too much if I ask DMD to provide a compiler
flag that makes it return bytes and shorts for operations on them? So the deal
would be, if you use this compiler flag, code behavior would be different from
that of C/C++.
Having compiler
On Tue, 11 Dec 2012 09:47:33 -0800
Walter Bright newshou...@digitalmars.com wrote:
On 12/11/2012 5:24 AM, d coder wrote:
Would I be asking for too much if I ask DMD to provide a compiler
flag that makes it return bytes and shorts for operations on them?
So the deal would be, if you use
On Tuesday, 11 December 2012 at 16:09:14 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 8:24 AM, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just
allow the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b +
On 12/11/2012 10:12 AM, Nick Sabalausky wrote:
Let's not entertain any thoughts of allowing D to venture down that
path.
No worries there :-) I feel pretty dang strongly about this issue, from bad
experience.
Even if a language behaves wrong, it is still usable if it is predictable.
On Tuesday, 11 December 2012 at 14:02:52 UTC, d coder wrote:
On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander
peter.alexander...@gmail.com wrote:
That's the whole point. What you are doing is dangerous, so it
requires
the cast.
What I am doing is not dangerous. I am operating at
On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
newshou...@digitalmars.comwrote:
No worries there :-) I feel pretty dang strongly about this issue, from
bad experience.
Even if a language behaves wrong, it is still usable if it is
predictable.
Agreed.
How about this.
1. Let char and short
On Wednesday, 12 December 2012 at 03:10:15 UTC, d coder wrote:
On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
newshou...@digitalmars.comwrote:
No worries there :-) I feel pretty dang strongly about this
issue, from
bad experience.
Even if a language behaves wrong, it is still usable if it is
38 matches
Mail list logo
