• QUS (14/14) Aug 25 2003 The small piece of code, just a class named Vector and method set to set...
• Helmut Leitner (7/26) Aug 25 2003 Nothing. You have to use "new".
• Philippe Mori (20/41) Aug 25 2003 Then in case like that the compiler should produce an error as
• Patrick Down (3/17) Aug 25 2003 Nothing, all objects in D are allocated on the heap. For my own vector
• Mike Wynn (7/29) Aug 25 2003 its
• Matthew Wilson (2/6) Aug 26 2003 Is it legal to create an auto instance of a class that is not auto?
• Patrick Down (2/8) Aug 26 2003
• Matthew Wilson (5/14) Aug 26 2003 when
• QUS (5/27) Aug 27 2003 Hmm... I just wonder... How would it work performance-wise in a game? I
• Marcel Strik (7/38) Oct 23 2003 I'm actually wondering the same thing. I did a little test where I had a...
• Sean L. Palmer (22/33) Oct 24 2003 In U.S. and Japan it's 60 times per second. ;)
• Marcel (8/33) Oct 24 2003 (...)
• Sean L. Palmer (4/14) Oct 24 2003 In D, what you want is a struct, not a class.
• Marcel (7/24) Oct 24 2003 Indeed, but to my mind that kinds of defeats the whole OO paradigm. I
• davepermen (7/12) Oct 24 2003 structs can have member functions and operators, just not ctors/dtors.
• ssuukk (3/5) Oct 24 2003 I will try that today :-) Well - you see - my game will depend heavily
• Marcel (8/27) Oct 24 2003

"QUS" <qus go2.pl> writes:

The small piece of code, just a class named Vector and method set to set its
x,y and z:

class Vector
{
 public:
 real a,b,c;
 this(real aa, real bb, real cc){set(aa,bb,cc);}
 this(){set(0,0,0);}
  void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
}

And now:

Vector a;
a.set(3,4,5);

gives access violation. Newing 'a' helps though. What am I doing wrong?

Helmut Leitner <leitner hls.via.at> writes:

QUS wrote:
 
 The small piece of code, just a class named Vector and method set to set its
 x,y and z:
 
 class Vector
 {
  public:
  real a,b,c;
  this(real aa, real bb, real cc){set(aa,bb,cc);}
  this(){set(0,0,0);}
   void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
 }
 
 And now:
 
 Vector a;
 a.set(3,4,5);
 
 gives access violation. Newing 'a' helps though. What am I doing wrong?

Nothing. You have to use "new". 

"Object o;" doesn't create an Object, but only a variable to hold a 
reference to an Object. It's like a pointer in C. 

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

"Philippe Mori" <philippe_mori hotmail.com> writes:

 The small piece of code, just a class named Vector and method set to set


its
 x,y and z:

 class Vector
 {
  public:
  real a,b,c;
  this(real aa, real bb, real cc){set(aa,bb,cc);}
  this(){set(0,0,0);}
   void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
 }

 And now:

 Vector a;
 a.set(3,4,5);

 gives access violation. Newing 'a' helps though. What am I doing wrong?

 Nothing. You have to use "new".

 "Object o;" doesn't create an Object, but only a variable to hold a
 reference to an Object. It's like a pointer in C.

Then in case like that the compiler should produce an error as
we are calling a member of an object that was not created or
at least give a warning...

IMO, we should not allows to call non-static member function
on an object that is known to be null...

Also speaking of that, we should have a way to indicate weither
parameters can be null (I would vote for no by default).

class A { }
void f(in A a) { ... }

A a;
f(a);    // should it be allowed ?

We should have a modifier for that... and the compiler would
be able to do compile and run-time checks as appropriate.

It could maybe be usefull to have modifier or attributes to
control object creation...

- can it be created only on stack (auto modifier), only with
new (no modifier) or both... or with alloca... or placement...
- does we allows the declaration of null object or the object
must be newed...

Patrick Down <Patrick_member pathlink.com> writes:

In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...
The small piece of code, just a class named Vector and method set to set its
x,y and z:

class Vector
{
 public:
 real a,b,c;
 this(real aa, real bb, real cc){set(aa,bb,cc);}
 this(){set(0,0,0);}
  void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
}

And now:

Vector a;
a.set(3,4,5);

gives access violation. Newing 'a' helps though. What am I doing wrong?

Nothing, all objects in D are allocated on the heap.  For my own vector
class I used a struct which can be allocated on the stack.  

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bid9ai$13eo$1 digitaldaemon.com...
 In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...
The small piece of code, just a class named Vector and method set to set


its
x,y and z:

class Vector
{
 public:
 real a,b,c;
 this(real aa, real bb, real cc){set(aa,bb,cc);}
 this(){set(0,0,0);}
  void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
}

And now:

Vector a;
a.set(3,4,5);

gives access violation. Newing 'a' helps though. What am I doing wrong?

 Nothing, all objects in D are allocated on the heap.  For my own vector
 class I used a struct which can be allocated on the stack.

you can use
auto Vector a;
it should be created for you (not on the stack, but will be destroyed when
it goes out of scope).

"Matthew Wilson" <matthew stlsoft.org> writes:

 you can use
 auto Vector a;
 it should be created for you (not on the stack, but will be destroyed when
 it goes out of scope).

Is it legal to create an auto instance of a class that is not auto?

I mean I think it's a good thing, just not aware of rule.

Patrick Down <Patrick_member pathlink.com> writes:

In article <bigl88$6gl$1 digitaldaemon.com>, Matthew Wilson says...
 you can use
 auto Vector a;
 it should be created for you (not on the stack, but will be destroyed when
 it goes out of scope).

Is it legal to create an auto instance of a class that is not auto?\

Yes

I mean I think it's a good thing, just not aware of rule.

"Matthew Wilson" <matthew stlsoft.org> writes:

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bignu2$ahb$1 digitaldaemon.com...
 In article <bigl88$6gl$1 digitaldaemon.com>, Matthew Wilson says...
 you can use
 auto Vector a;
 it should be created for you (not on the stack, but will be destroyed



when
 it goes out of scope).

Is it legal to create an auto instance of a class that is not auto?\

 Yes

Well I guess I can imagine rationale for that design, but still it seems a
pain. :(

"QUS" <qus go2.pl> writes:

 In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...
The small piece of code, just a class named Vector and method set to set


its
x,y and z:

class Vector
{
 public:
 real a,b,c;
 this(real aa, real bb, real cc){set(aa,bb,cc);}
 this(){set(0,0,0);}
  void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
}

And now:

Vector a;
a.set(3,4,5);

gives access violation. Newing 'a' helps though. What am I doing wrong?

 Nothing, all objects in D are allocated on the heap.  For my own vector
 class I used a struct which can be allocated on the stack.

Hmm... I just wonder... How would it work performance-wise in a game? I
guess each operator overloading function also has to new its return value?
Now what if I have a solar system with (currently!) over 100 bodies, for
which I have to calculate postions 50 times a second? :-)

Marcel Strik <mars_888 hotmail.com> writes:

"QUS" <qus go2.pl> wrote in news:bihnmc$1tg1$1 digitaldaemon.com:

 In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...
The small piece of code, just a class named Vector and method set to
set 


 its
x,y and z:

class Vector
{
 public:
 real a,b,c;
 this(real aa, real bb, real cc){set(aa,bb,cc);}
 this(){set(0,0,0);}
  void set(real aa, real bb, real cc){a=aa; b=bb; c=cc;}
}

And now:

Vector a;
a.set(3,4,5);

gives access violation. Newing 'a' helps though. What am I doing
wrong? 

 Nothing, all objects in D are allocated on the heap.  For my own
 vector class I used a struct which can be allocated on the stack.

 Hmm... I just wonder... How would it work performance-wise in a game?
 I guess each operator overloading function also has to new its return
 value? Now what if I have a solar system with (currently!) over 100
 bodies, for which I have to calculate postions 50 times a second? :-)

I'm actually wondering the same thing. I did a little test where I had a 
vector like object being created every frame and the memory usage did 
seem to fluctuate heavily, though the test wasn't extensive enough to 
decide if performance was influenced. Creating the object once and 
reusing it resulted in a nice steady memory usage. Perhaps anyone else 
has more experience with the performance issues.

"Sean L. Palmer" <palmer.sean verizon.net> writes:

"Marcel Strik" <mars_888 hotmail.com> wrote in message
news:Xns941E7B4B3935marsvulcanushotmail 63.105.9.61...
 "QUS" <qus go2.pl> wrote in news:bihnmc$1tg1$1 digitaldaemon.com:
 Hmm... I just wonder... How would it work performance-wise in a game?
 I guess each operator overloading function also has to new its return
 value? Now what if I have a solar system with (currently!) over 100
 bodies, for which I have to calculate postions 50 times a second? :-)


In U.S. and Japan it's 60 times per second.  ;)

That would suck.  You should use a struct.  The only thing you lose is
ctors.  You gain a heckuva lot of performance.  You can always make
"constructor" or "factory" functions, but it would be nice if they could be
ctors.  Easy on the namespace.  Your factories can be static functions of
the struct I guess.

 I'm actually wondering the same thing. I did a little test where I had a
 vector like object being created every frame and the memory usage did
 seem to fluctuate heavily, though the test wasn't extensive enough to
 decide if performance was influenced. Creating the object once and
 reusing it resulted in a nice steady memory usage. Perhaps anyone else
 has more experience with the performance issues.

In real games, the heap is idle while the game is being played, for the most
part.  We go to great lengths to ensure nobody is allocating or leaking
memory.  All per-frame allocations go thru pools, and that's only if they
absolutely have to be allocated per frame.

You have to be that strict to ensure you have consistent framerate, and the
game doesn't break after you play it a few hours.  We usually push the limit
pretty close on memory usage, so if we don't keep a tight watch on what's
allocated where, it won't all fit.  You wouldn't want your game to break if
you enter the room from the north, but not if you enter from the south,
would you?  That kind of stuff is a testing nightmare waiting to happen.

I like how D has garbage collection and that eliminates a whole class of
errors, but I have seen situations where one stray 40-odd-byte allocation
causes all kinds of havoc.

Sean

Marcel <mars_888 hotmail.com> writes:

"Sean L. Palmer" <palmer.sean verizon.net> wrote in
news:bnakvr$nss$1 digitaldaemon.com: 
 
 In U.S. and Japan it's 60 times per second.  ;)
 
 That would suck.  You should use a struct.  The only thing you lose is
 ctors.  You gain a heckuva lot of performance.  You can always make
 "constructor" or "factory" functions, but it would be nice if they
 could be ctors.  Easy on the namespace.  Your factories can be static
 functions of the struct I guess.

(...)
 In real games, the heap is idle while the game is being played, for
 the most part.  We go to great lengths to ensure nobody is allocating
 or leaking memory.  All per-frame allocations go thru pools, and
 that's only if they absolutely have to be allocated per frame.

That's what I thought and I assume that the same still goes with D, but it 
would be nice to be able to use vector classes and such without taking a 
big performance hit.

 You have to be that strict to ensure you have consistent framerate,
 and the game doesn't break after you play it a few hours.  We usually
 push the limit pretty close on memory usage, so if we don't keep a
 tight watch on what's allocated where, it won't all fit.  You wouldn't
 want your game to break if you enter the room from the north, but not
 if you enter from the south, would you?  That kind of stuff is a
 testing nightmare waiting to happen. 
 
 I like how D has garbage collection and that eliminates a whole class
 of errors, but I have seen situations where one stray 40-odd-byte
 allocation causes all kinds of havoc.
 
 Sean

Those kinds of errors are allways the best ;)

- Marcel

"Sean L. Palmer" <palmer.sean verizon.net> writes:

"Marcel" <mars_888 hotmail.com> wrote in message
news:Xns941E6E23FD5A1marsvulcanushotmail 63.105.9.61...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in
 news:bnakvr$nss$1 digitaldaemon.com:
 That would suck.  You should use a struct.  The only thing you lose is
 ctors.  You gain a heckuva lot of performance.  You can always make
 "constructor" or "factory" functions, but it would be nice if they
 could be ctors.  Easy on the namespace.  Your factories can be static
 functions of the struct I guess.


 That's what I thought and I assume that the same still goes with D, but it
 would be nice to be able to use vector classes and such without taking a
 big performance hit.

In D, what you want is a struct, not a class.

Sean

Marcel <mars_888 hotmail.com> writes:

"Sean L. Palmer" <palmer.sean verizon.net> wrote in
news:bnapbb$1210$1 digitaldaemon.com: 

 "Marcel" <mars_888 hotmail.com> wrote in message
 news:Xns941E6E23FD5A1marsvulcanushotmail 63.105.9.61...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in
 news:bnakvr$nss$1 digitaldaemon.com:
 That would suck.  You should use a struct.  The only thing you lose
 is ctors.  You gain a heckuva lot of performance.  You can always
 make "constructor" or "factory" functions, but it would be nice if
 they could be ctors.  Easy on the namespace.  Your factories can be
 static functions of the struct I guess.


 
 That's what I thought and I assume that the same still goes with D,
 but it would be nice to be able to use vector classes and such
 without taking a big performance hit.

 
 In D, what you want is a struct, not a class.
 
 Sean

Indeed, but to my mind that kinds of defeats the whole OO paradigm. I 
personally would prefer to use A + B instead of Vector.Add( A, B ). 
While  programming in D I get a sense that it allows for clearer OO 
programming than C++ allows, but it's a shame that you have to use 
structs for these types of problems to get good performance.

davepermen <davepermen_member pathlink.com> writes:

structs can have member functions and operators, just not ctors/dtors.

would be nice if we could overload the name of a struct with a function.. so

struct float4 { ... }

float4 float4(...) { float4 v; ... return v; }

would be possible. that would still non-allow ctors/dtors, but would be nicer
than some explicit name like makefloat4 or what ever..

i can A + B with my struct, can you?:D

Indeed, but to my mind that kinds of defeats the whole OO paradigm. I 
personally would prefer to use A + B instead of Vector.Add( A, B ). 
While  programming in D I get a sense that it allows for clearer OO 
programming than C++ allows, but it's a shame that you have to use 
structs for these types of problems to get good performance.

ssuukk <ssuukk .go2.pl> writes:

 i can A + B with my struct, can you?:D
 

I will try that today :-)  Well - you see - my game will depend heavily 
on variable level of detail (have you seen Frontier?) so I think I can't 
ge away without heap, but vectors allocated on stack will be nice!

Marcel <mars_888 hotmail.com> writes:

davepermen <davepermen_member pathlink.com> wrote in
news:bnb22k$1dmf$1 digitaldaemon.com: 

 structs can have member functions and operators, just not ctors/dtors.
 
 would be nice if we could overload the name of a struct with a
 function.. so 
 
 struct float4 { ... }
 
 float4 float4(...) { float4 v; ... return v; }
 
 would be possible. that would still non-allow ctors/dtors, but would
 be nicer than some explicit name like makefloat4 or what ever..
 
 i can A + B with my struct, can you?:D
 
Indeed, but to my mind that kinds of defeats the whole OO paradigm. I 
personally would prefer to use A + B instead of Vector.Add( A, B ). 
While  programming in D I get a sense that it allows for clearer OO 
programming than C++ allows, but it's a shame that you have to use 
structs for these types of problems to get good performance.


 
 

Works like a charm, thanks! I was under the impression that a struct
couldn't have member function in D, but I guess I mixed up normal member
functions with ctors/dtors when reading the docs. 

- Marcel