D - HOW can I make a local stack variable?!
- 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.
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
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
itsThe small piece of code, just a class named Vector and method set to setThen 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...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.
Aug 25 2003
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
"Patrick Down" <Patrick_member pathlink.com> wrote in message news:bid9ai$13eo$1 digitaldaemon.com...In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...itsThe small piece of code, just a class named Vector and method set to setyou 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).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
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
In article <bigl88$6gl$1 digitaldaemon.com>, Matthew Wilson says...Yesyou 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
"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...whenyou can use auto Vector a; it should be created for you (not on the stack, but will be destroyedWell I guess I can imagine rationale for that design, but still it seems a pain. :(Yesit goes out of scope).Is it legal to create an auto instance of a class that is not auto?\
Aug 26 2003
In article <bid1fk$nar$1 digitaldaemon.com>, QUS says...itsThe small piece of code, just a class named Vector and method set to setHmm... 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? :-)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 27 2003
"QUS" <qus go2.pl> wrote in news:bihnmc$1tg1$1 digitaldaemon.com: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 article <bid1fk$nar$1 digitaldaemon.com>, QUS says...itsThe small piece of code, just a class named Vector and method set to setHmm... 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? :-)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.
Oct 23 2003
"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: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.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.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
"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. SeanThose kinds of errors are allways the best ;) - Marcel
Oct 24 2003
"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
"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...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."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
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?:DIndeed, 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
i can A + B with my struct, can you?:DI 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!
Oct 24 2003
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?:DWorks 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. - MarcelIndeed, 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