www.digitalmars.com         C & C++   DMDScript  

D - HOW can I make a local stack variable?!

reply "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?
Aug 25 2003
next sibling parent reply 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
Aug 25 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 The small piece of code, just a class named Vector and method set to set


 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...
Aug 25 2003
prev sibling parent reply 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.
Aug 25 2003
next sibling parent reply "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


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.

auto Vector a; it should be created for you (not on the stack, but will be destroyed when it goes out of scope).
Aug 25 2003
parent reply "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.
Aug 26 2003
parent reply 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.

Aug 26 2003
parent "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



 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. :(
Aug 26 2003
prev sibling parent reply "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


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.

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? :-)
Aug 27 2003
parent reply 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 


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.

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.
Oct 23 2003
parent reply "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
Oct 24 2003
parent reply 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
Oct 24 2003
parent reply "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
Oct 24 2003
parent reply 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.
Oct 24 2003
parent reply 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.

Oct 24 2003
next sibling parent ssuukk <ssuukk .go2.pl> writes:
 i can A + B with my struct, can you?:D
 

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!
Oct 24 2003
prev sibling parent 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
Oct 24 2003