On 10/31/12, Adam D. Ruppe destructiona...@gmail.com wrote:
On Wednesday, 31 October 2012 at 22:46:17 UTC, Andrej Mitrovic
wrote:
I wonder if this is low-hanging fruit to implement in the DMD
frontend.
I tried it and found getting almost there is easy... but getting
it
to work in a bunch
in my matrix class:
If I do this I get an error:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new Vector3(0, 0, 0);
Vector3 test2 = test + mtest.GetColumn(2);
I get the error Error: mtest.GetColumn(x) is not an lvalue
But the following works:
Matrix33 mtest = new
();
mtest.SetIdentity();
Vector3 test1 = new Vector3(0, 0, 0);
Vector3 test2 = test + mtest.GetColumn(2);
I get the error Error: mtest.GetColumn(x) is not an lvalue
But the following works:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new Vector3(0, 0, 0);
Vector3 temp
:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new Vector3(0, 0, 0);
Vector3 test2 = test + mtest.GetColumn(2);
I get the error Error: mtest.GetColumn(x) is not an lvalue
But the following works:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new
an error:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new Vector3(0, 0, 0);
Vector3 test2 = test + mtest.GetColumn(2);
I get the error Error: mtest.GetColumn(x) is not an lvalue
But the following works:
Matrix33 mtest = new Matrix33();
mtest.SetIdentity();
Vector3 test1 = new
On 5/1/2011 3:53 PM, Dmitry Olshansky wrote:
Ehm.. Well, first things first: you shouldn't use classes for
lightweight plain data things like vectors. There are structs for
that. In general, structs are value-like objects living on the stack
while classes are reference-like objects living on
On 1/05/11 2:53 PM, Dmitry Olshansky wrote:
Ehm.. Well, first things first: you shouldn't use classes for
lightweight plain data things like vectors. There are structs for
that. In general, structs are value-like objects living on the stack
while classes are reference-like objects living on the
On 01.05.2011 19:31, Peter Alexander wrote:
On 1/05/11 2:53 PM, Dmitry Olshansky wrote:
Ehm.. Well, first things first: you shouldn't use classes for
lightweight plain data things like vectors. There are structs for
that. In general, structs are value-like objects living on the stack
while
Hello Benjamin,
Am 08.10.2010 11:13, schrieb Lars T. Kyllingstad:
On Fri, 08 Oct 2010 09:33:22 +0200, Benjamin Thaut wrote:
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue so I wonder which is the correct way
to do this:
vec4 Normalize
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue so I wonder which is the correct way to
do this:
vec4 Normalize() const { ... } //won't work, not a lvalue
ref vec4 Normalize() const {
vec4 temp;
...
return temp;
} //will this lead
Benjamin Thaut wrote:
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue so I wonder which is the correct way to
do this:
vec4 Normalize() const { ... } //won't work, not a lvalue
ref vec4 Normalize() const {
vec4 temp;
...
return temp
Benjamin Thaut c...@benjamin-thaut.de wrote:
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue so I wonder which is the correct way to
do this:
vec4 Normalize() const { ... } //won't work, not a lvalue
ref vec4 Normalize() const {
vec4
On Fri, 08 Oct 2010 09:33:22 +0200, Benjamin Thaut wrote:
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue so I wonder which is the correct way to
do this:
vec4 Normalize() const { ... } //won't work, not a lvalue
ref vec4 Normalize
On Fri, 08 Oct 2010 09:26:19 -0400, Benjamin Thaut
c...@benjamin-thaut.de wrote:
Am 08.10.2010 11:13, schrieb Lars T. Kyllingstad:
On Fri, 08 Oct 2010 09:33:22 +0200, Benjamin Thaut wrote:
Hi, I'm writing a vec4 math struct and I have a method of which the
return value has to be a lvalue
Steven Schveighoffer schvei...@yahoo.com wrote:
The correct way is to use auto ref as the parameter:
struct vec4
{
...
vec4 Normalize(auto ref const(vec4) param) {...}
}
But AFAIK, this doesn't really work.
It doesn't, no. I'm not even sure it's scheduled for inclusion.
Also, with
On Fri, 08 Oct 2010 09:51:59 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Steven Schveighoffer schvei...@yahoo.com wrote:
The correct way is to use auto ref as the parameter:
struct vec4
{
...
vec4 Normalize(auto ref const(vec4) param) {...}
}
But AFAIK, this doesn't really
Rainer Deyke wrote:
Jarrett Billingsley wrote:
Members are always initialized to the default initializer for their
type, which is usually 0 for integer types and NAN for floating point
types. This eliminates an entire class of obscure problems that come
from neglecting to initialize a member
Steven Schveighoffer wrote:
What is i referencing when you call:
foo();
Is this an argument for making
int j;
void foo(ref int i = j);
foo():
legal D?
-manfred
On Mon, 31 Aug 2009 13:00:34 -0400, Manfred_Nowak svv1...@hotmail.com
wrote:
Steven Schveighoffer wrote:
What is i referencing when you call:
foo();
Is this an argument for making
int j;
void foo(ref int i = j);
foo():
legal D?
No, I'm just trying to explain why having a
On Mon, 31 Aug 2009 14:55:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
It's possible that something like what you wrote could work (although
I'd write it foo(ref int i = j)).
In fact, it does work, in D1 no less.
# cat testme.d
import tango.io.Stdout;
int j;
void foo(ref
Jarrett Billingsley wrote:
Although teeechnically speaking that would be illegal code. The D
spec says that it's not legal to use the value of uninitialized
variables. Default initialization is kind of a poor man's substitute
for actual flow control which determines that. By relying on
On Sun, Aug 30, 2009 at 5:34 AM, Rainer Deykerain...@eldwood.com wrote:
Jarrett Billingsley wrote:
Although teeechnically speaking that would be illegal code. The D
spec says that it's not legal to use the value of uninitialized
variables. Default initialization is kind of a poor man's
On Sun, Aug 30, 2009 at 7:13 AM, grauzonen...@example.net wrote:
Although teeechnically speaking that would be illegal code. The D
spec says that it's not legal to use the value of uninitialized
variables. Default initialization is kind of a poor man's substitute
for actual flow control
Steven Schveighoffer wrote:
On Sat, 29 Aug 2009 20:15:55 -0400, Ellery Newcomer
ellery-newco...@utulsa.edu wrote:
void blah(out bool a = false){
// blah blah blah
}
compile time use of blah results in error.
Am I doing anything wrong?
out implies a reference. You can't have a
On Sun, Aug 30, 2009 at 3:14 PM, Jarrett
Billingsleyjarrett.billings...@gmail.com wrote:
On Sun, Aug 30, 2009 at 3:02 PM, Rainer Deykerain...@eldwood.com wrote:
The purpose of default initialization is not to find or reduce bugs, but
to reduce the size of legal programs.
I'm wondering where
Jarrett Billingsley wrote:
On Sun, Aug 30, 2009 at 3:02 PM, Rainer Deykerain...@eldwood.com wrote:
The purpose of default initialization is not to find or reduce bugs, but
to reduce the size of legal programs.
I'm wondering where the heck you got that justification.
By looking at the actual
Jarrett Billingsley wrote:
Members are always initialized to the default initializer for their
type, which is usually 0 for integer types and NAN for floating point
types. This eliminates an entire class of obscure problems that come
from neglecting to initialize a member in one of the
On Sun, Aug 30, 2009 at 12:24 AM, Ary Borenszweiga...@esperanto.org.ar wrote:
Steven Schveighoffer escribió:
On Sat, 29 Aug 2009 20:15:55 -0400, Ellery Newcomer
ellery-newco...@utulsa.edu wrote:
void blah(out bool a = false){
// blah blah blah
}
compile time use of blah results in
The Anh Tran wrote:
Hi,
When porting from c++ to D, i encounter this strange discrimination:
1. Built-in AA:
int[int] arr;
arr[123] += 12345;
arr[321]++;
2. Tango HashMap:
auto hm = new HashMap!(int, int)();
hm[123] += 12345; // error not lvalue
hm[123
Daniel Keep wrote:
You could try the Tango IRC channel:
That, or the Tango forums:
http://dsource.org/projects/tango/forums
You can report problems with Tango via the ticket system:
http://dsource.org/projects/tango/report (New Ticket is down the
bottom of the page.)
I tried to register. But
Hi,
When porting from c++ to D, i encounter this strange discrimination:
1. Built-in AA:
int[int] arr;
arr[123] += 12345;
arr[321]++;
2. Tango HashMap:
auto hm = new HashMap!(int, int)();
hm[123] += 12345; // error not lvalue
hm[123
The Anh Tran wrote:
Hi,
When porting from c++ to D, i encounter this strange discrimination:
1. Built-in AA:
int[int] arr;
arr[123] += 12345;
arr[321]++;
2. Tango HashMap:
auto hm = new HashMap!(int, int)();
hm[123] += 12345; // error not lvalue
hm[123
)();
hm[123] += 12345; // error not lvalue
hm[123]++; // error
D document says current opIndexAssign does not work as lvalue. But why
can builtin AA can that? How can i copy builtin AA behaviour?
--
Forgive my noob, where is the place to ask question, report bug
101 - 133 of 133 matches
Mail list logo
