FxSceneObject non-const member functions
by Tim Doty · in Torque Game Builder · 06/29/2005 (5:58 pm) · 17 replies
Is there any reason why the various get functions of fxSceneObject2D aren't const? getParentPhysicsModel() isn't const, which is the root of getLinearVelocity() and others, which then are obviously not const either. I don't see any of the various get functions modifying the class, nor can I think of any reason why they would.
Just curious if I overlooked some reason to not make those functions const.
Tim Doty
Just curious if I overlooked some reason to not make those functions const.
Tim Doty
About the author
#2
The physics stuff, although a seperate class, is currently being treated as part of fxSceneObject2D. That's why all of its internals are public anyway. fxPhysics2D returns all its members as references so that they can be access directly anyway.
To be honest, fxPhysics2D (so hard to not call it t2dPhysics and t2dSceneObject) have changed so much since v1.0.2 that I can hardly remember how it was. ;)
EDIT: Just noticed that you were talking about fxSceneObject2D accessors! No reason or conspiracy really but they only return stuff by value anyway.
- Melv.
07/14/2005 (8:24 am)
Tim,The physics stuff, although a seperate class, is currently being treated as part of fxSceneObject2D. That's why all of its internals are public anyway. fxPhysics2D returns all its members as references so that they can be access directly anyway.
To be honest, fxPhysics2D (so hard to not call it t2dPhysics and t2dSceneObject) have changed so much since v1.0.2 that I can hardly remember how it was. ;)
EDIT: Just noticed that you were talking about fxSceneObject2D accessors! No reason or conspiracy really but they only return stuff by value anyway.
- Melv.
#3
That's no excuse for not being const-safe. Const-safeness is a viral thing: when in one place, it must spread to encompass virtually everything that the place depends on, and then everything after that, and so forth. So having library systems that aren't const-safe is always painful to those of us who believe in const safety.
I imagine that it has something to do with the focus of T2D being the script interface and not the code. So niceties like const-safeness and so forth aren't available.
I would suggest, rather than having to hack every T2D release for these kinds of things, instead store mutable pointers to T2D objects in your classes.
07/14/2005 (11:59 am)
Quote:No reason or conspiracy really but they only return stuff by value anyway.
That's no excuse for not being const-safe. Const-safeness is a viral thing: when in one place, it must spread to encompass virtually everything that the place depends on, and then everything after that, and so forth. So having library systems that aren't const-safe is always painful to those of us who believe in const safety.
I imagine that it has something to do with the focus of T2D being the script interface and not the code. So niceties like const-safeness and so forth aren't available.
I would suggest, rather than having to hack every T2D release for these kinds of things, instead store mutable pointers to T2D objects in your classes.
#4
@Smaug: My first thought was to just not make my call const. But, as you say its viral and there were const functions calling it and... it was easier to simply modify the engine. I wrote a longer bit explaining why I'm doing things the way I am, but it boils down to a choice between multiple inheritance to achieve what I consider good OO design and using a pointer to the T2D objects. In the latter case I can, as you suggest, make things mutable. Maybe I will.
I'm still very much learning T2D and my programming time is very limited and intermittent so it is slow.
07/14/2005 (2:54 pm)
@Melv: Thanks for the answer. I guess I'll know more when the next version is out, but any chance of declaring functions as const when they are (to avoid me having to patch the source)?@Smaug: My first thought was to just not make my call const. But, as you say its viral and there were const functions calling it and... it was easier to simply modify the engine. I wrote a longer bit explaining why I'm doing things the way I am, but it boils down to a choice between multiple inheritance to achieve what I consider good OO design and using a pointer to the T2D objects. In the latter case I can, as you suggest, make things mutable. Maybe I will.
I'm still very much learning T2D and my programming time is very limited and intermittent so it is slow.
#5
Hmm, I tend to use Pimpl frequently for such classes, so I tend to avoid "is a" relationships directly. Plus, in my current game, my entities need to have multiple scene objects in order to define a real object (mostly to get around not being able to have multiple collision volumes and arbitrary rotation points in T2D), so multiple inheritance isn't even a choice for me.
07/15/2005 (2:20 pm)
Quote:but it boils down to a choice between multiple inheritance to achieve what I consider good OO design and using a pointer to the T2D objects.
Hmm, I tend to use Pimpl frequently for such classes, so I tend to avoid "is a" relationships directly. Plus, in my current game, my entities need to have multiple scene objects in order to define a real object (mostly to get around not being able to have multiple collision volumes and arbitrary rotation points in T2D), so multiple inheritance isn't even a choice for me.
#6
07/15/2005 (2:35 pm)
@Smaug: interesting way of dealing with the issue. As it turns out I decided that using a public pointer to fxStaticSprite2D was the best way of dealing with things (for multiple reasons). I appreciate the input and it was thinking through what you said that got me re-evaluating the way I was doing things. Thanks!
#7
With regards to multiple collision "volumes"; as I said before in a response to you, each object can have multiple 'volumes' in stock T2D. In the latest version we've now got stock swept-collision detections for ellipse/poly and stock responses as well as virtual core handlers for custom detection/responses.
I'm sure I'll hack this better though in the next release man. ;)
- Melv.
07/15/2005 (2:41 pm)
@Smaug: My saying "No reason or conspiracy really" seems to have value "something to do with the focus of T2D being the script interface and not the code" seems conspirital. ;) There's lots of const-safe stuff in T2D but where there isn't, well, I take a bow, I'm sure your code is throughly textbook perfect in everyway!With regards to multiple collision "volumes"; as I said before in a response to you, each object can have multiple 'volumes' in stock T2D. In the latest version we've now got stock swept-collision detections for ellipse/poly and stock responses as well as virtual core handlers for custom detection/responses.
I'm sure I'll hack this better though in the next release man. ;)
- Melv.
#8
07/15/2005 (2:44 pm)
@Melv: sounds like good progress. Is it reasonable to expect more const-safe in the next version then?
#9
That aside, yourself and Smaug do bring valid points and yes, I accept that there is much room for improvement in lots of areas, const-safe being one of them. There'll be many more improvements such as dOxygenise commenting (something I should've done from the start), C++ doco (when I get some time) and generally more exposure of how to form applications the C++ way.
Despite the rumours, doing stuff in C++ with T2D is real easy. Now we've just got to get you guys some documentation via TDN.
- Melv.
07/15/2005 (2:54 pm)
It's certainly reasonable to expect more coding-care to be taken now that I'm not coding at a pace that would kill a horse. Smaug would probably think this as an excuse but I'm amazed that T2D even worked being as I started writing it a week after my daughter was born and total const-safe code was the least of my worries during my 2 hours sleep a night and that's no BS.That aside, yourself and Smaug do bring valid points and yes, I accept that there is much room for improvement in lots of areas, const-safe being one of them. There'll be many more improvements such as dOxygenise commenting (something I should've done from the start), C++ doco (when I get some time) and generally more exposure of how to form applications the C++ way.
Despite the rumours, doing stuff in C++ with T2D is real easy. Now we've just got to get you guys some documentation via TDN.
- Melv.
#10
As for T2D? I'll be happier when it is release version, but I'm already very happy. I still prefer coding for T2D in TorqueScript, but I saw the wisdom in getting the objects done in c++. I'm getting very close to the same (improved) level of implementation as I had in script and am looking forward to some more rapid script development.
I don't think the C++ coding is hard, at least not for object creation. A bit obtuse at first due to documentation consisting of comments scattered in the code, but it quickly becomes cookie-cutter for what I'm doing.
Now, back to the 15 minutes of coding I get for the night ;^)
07/15/2005 (3:14 pm)
@Melv: I certainly think you're doing a knock up job. I'm still impressed you got as much done as you did with your daughter being born. Quite an accomplishment.As for T2D? I'll be happier when it is release version, but I'm already very happy. I still prefer coding for T2D in TorqueScript, but I saw the wisdom in getting the objects done in c++. I'm getting very close to the same (improved) level of implementation as I had in script and am looking forward to some more rapid script development.
I don't think the C++ coding is hard, at least not for object creation. A bit obtuse at first due to documentation consisting of comments scattered in the code, but it quickly becomes cookie-cutter for what I'm doing.
Now, back to the 15 minutes of coding I get for the night ;^)
#11
You have to admit that your statement that "they only return stuff by value anyway" sounds suspiciously like "I didn't think that they needed to be const-safe" rather than what you seem to have intended which was "Oops, I made a mistake, and they will be corrected in the next release." One of these is an unintended error, which is perfectly forgivable, while the other might indicate something else. All I really wanted to know was whether you considered it to be a mistake and whether or not you planned on fixing it.
Not so much conspirital, but simply acknowledging that you had certain priorities that put an emphesis on certain features that therefore made certain other features less feature-complete. Or, at least, less well polished.
07/15/2005 (5:18 pm)
Quote:My saying "No reason or conspiracy really" seems to have value "something to do with the focus of T2D being the script interface and not the code" seems conspirital. ;) There's lots of const-safe stuff in T2D but where there isn't, well, I take a bow, I'm sure your code is throughly textbook perfect in everyway!
You have to admit that your statement that "they only return stuff by value anyway" sounds suspiciously like "I didn't think that they needed to be const-safe" rather than what you seem to have intended which was "Oops, I made a mistake, and they will be corrected in the next release." One of these is an unintended error, which is perfectly forgivable, while the other might indicate something else. All I really wanted to know was whether you considered it to be a mistake and whether or not you planned on fixing it.
Quote:My saying "No reason or conspiracy really" seems to have value "something to do with the focus of T2D being the script interface and not the code" seems conspirital.
Not so much conspirital, but simply acknowledging that you had certain priorities that put an emphesis on certain features that therefore made certain other features less feature-complete. Or, at least, less well polished.
#12
To me means that he had much higher priorties, like taking care of his newborn... and getting the rest of the engine done.
but he didn't make a mistake, at least in my opinion he didn't. Sure there is a way to make the code more efficient and less error prone, but to me that doesn't read out mistake since there is always room for improvement. In development focusing on every little minor tweak is called "Feature Creep." Yeah this may be stretching it for this case, but if he worried about every single little optimization we wouldn't have T2D... so give him a break, I highly suggest not acting so superior and proud, it really doesn't become you.
07/15/2005 (5:24 pm)
ActuallyQuote:"they only return stuff by value anyway"
To me means that he had much higher priorties, like taking care of his newborn... and getting the rest of the engine done.
Quote:"Oops, I made a mistake, and they will be corrected in the next release."
but he didn't make a mistake, at least in my opinion he didn't. Sure there is a way to make the code more efficient and less error prone, but to me that doesn't read out mistake since there is always room for improvement. In development focusing on every little minor tweak is called "Feature Creep." Yeah this may be stretching it for this case, but if he worried about every single little optimization we wouldn't have T2D... so give him a break, I highly suggest not acting so superior and proud, it really doesn't become you.
#13
07/15/2005 (5:30 pm)
T2D is in Early Adopter anyways, you really have no excuse for the proud remarks Smaug. Have seen a lot of them from you and the cheapshots are really uncalled for.
#14
If all you really wanted to know was if I considered the fact that these functions return by value then you could simply of asked directly. To answer your question, I am a very experienced developer who understands the advantage of const-safe code and its propagation through the codebase. My point was to the level of severity of returning items that couldn't be modified. Passing references/pointers being a much more dangerous case rather than simply locking-down the code within the function itself. I was also obviously not refering to every function that was being discussed.
In the real world, sometimes you don't implement stuff as you know you should have and you end up going back to it, duck you head and quickly correct it. In nearly every project I've seen this happens because of the real-world thing they call time, you end up not doing the 'perfect' job if there is such a thing. The only exception to this is when I've written code that has to adhere to FDA rules where everything is completely locked-down and documented.
With that aside, I'd like to ask how your game is coming along as you've not posted much about it on the forums and I'm intreaged. Any screenshots or other info you can share?
- Melv.
07/16/2005 (1:13 am)
Smaug,If all you really wanted to know was if I considered the fact that these functions return by value then you could simply of asked directly. To answer your question, I am a very experienced developer who understands the advantage of const-safe code and its propagation through the codebase. My point was to the level of severity of returning items that couldn't be modified. Passing references/pointers being a much more dangerous case rather than simply locking-down the code within the function itself. I was also obviously not refering to every function that was being discussed.
In the real world, sometimes you don't implement stuff as you know you should have and you end up going back to it, duck you head and quickly correct it. In nearly every project I've seen this happens because of the real-world thing they call time, you end up not doing the 'perfect' job if there is such a thing. The only exception to this is when I've written code that has to adhere to FDA rules where everything is completely locked-down and documented.
With that aside, I'd like to ask how your game is coming along as you've not posted much about it on the forums and I'm intreaged. Any screenshots or other info you can share?
- Melv.
#15
Melv walks up, pulls the pin on the grenade, and quietly walks aways whistling. :-)
07/16/2005 (8:11 am)
With that aside, I'd like to ask how your game is coming along as you've not posted much about it on the forums and I'm intreaged. Any screenshots or other info you can share?Melv walks up, pulls the pin on the grenade, and quietly walks aways whistling. :-)
#16
07/16/2005 (5:14 pm)
:o) Thought I heard a distant boom 
Torque Owner Tim Doty
Tim Doty