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
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 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 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 fo
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
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, bu
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 co
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 becaus
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
> On 2012-22-13 04:12, Jonathan M Davis wrote:
>
> On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
>>
On 2012-22-13 04:12, Jonathan M Davis 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 done in D, and it's
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
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 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
> bbyt
On Wednesday, 12 December 2012 at 08:23:48 UTC, Simen Kjaeraas
wrote:
On 2012-09-12 00:12, js.mdnq 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
On 2012-17-12 10:12, Jonathan M Davis wrote:
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
On 2012-09-12 00:12, js.mdnq wrote:
> struct bbyte {
> byte value;
> ...
> }
>
> bbyte a; bbyte b;
>
> b = a + b; // uses bbyte's operators and casts to do the computation
and
> assi
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
> On 2012-09-12 00:12, js.mdnq 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 2012-09-12 00:12, js.mdnq 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 bbyte to built in
type
On Wednesday, 12 December 2012 at 03:10:15 UTC, d coder wrote:
On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
wrote:
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.
On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
wrote:
> 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" behave the C/C
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 byte/sh
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 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 Tue, 11 Dec 2012 09:47:33 -0800
Walter Bright 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 this compiler flag, cod
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 fl
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
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
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
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
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 ha
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 in
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
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 langua
On 12/11/12 8:03 AM, d coder wrote:
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra 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 from C. :-)
No, it
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra 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 from C. :-)
Regards
- Puneet
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 typ
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));
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 int
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));
}
38 matches
Mail list logo
