What's the reason Point3F's are initialized on Linux but not on OSX/Win32?
by Stefan Lundmark · in Torque 3D Professional · 10/21/2012 (10:50 am) · 8 replies
What's the reason Point3F's are initialized to (0, 0, 0) on Linux but not on OSX/Win32?
I never noticed it before but this was the case even in TGEA. I understand why if you're pedandic about nanosecond performance, but not why it's different between the platforms.
Anyone who knows?
I never noticed it before but this was the case even in TGEA. I understand why if you're pedandic about nanosecond performance, but not why it's different between the platforms.
Anyone who knows?
#2
10/21/2012 (1:11 pm)
It doesn't, but neither does MSVC or any other C++ compiler that I know of. :) That's why I'm confused, heh. 
#3
I reckon the only way to find out would be to actually remove the initialisation and see what happens, which I would do if I had a Linux environment.
10/21/2012 (1:25 pm)
This may have something to do with it (mPoint3.h):inline Point3F::Point3F()
#if defined(TORQUE_OS_LINUX)
: x(0.f), y(0.f), z(0.f)
#endif
{If you're asking why as in the reasoning behind this, I can't help you! It doesn't seem like any other of the point classes (i.e. Point2I) are initialised at all in their constructors. Potentially some of the users of Point3F try to read the point before writing to it, causing GCC to give warnings about uninitialised values?I reckon the only way to find out would be to actually remove the initialisation and see what happens, which I would do if I had a Linux environment.
#4
10/21/2012 (1:31 pm)
I searched and can't find anything on this. Perhaps it is to reduce compiler warnings for a particular version of GCC.
#5
Initializing those values won't break anything, but it's interesting to hear for what reason it exists. There's even a funny comment down there:
I guess it could be to stop GCC from spitting out warnings, I didn't think of that. Hmm.
To get back to my point: Look at Player and some of the other Point3F heavy classes. Their constructors are littered with all these Point3F's being assigned to Point3F (0, 0, 0). This not only clutters the code when it could be done implicitly in the constructor of Point3F, but is also (though the difference is very small) less efficient than initializing those three values in the Point3F with a initializer list.
10/21/2012 (2:03 pm)
I'm well aware of the implications and the #ifdef, I'm just curious why the creator of the code did it that way because to me it makes no sense.Initializing those values won't break anything, but it's interesting to hear for what reason it exists. There's even a funny comment down there:
// Uninitialized points are definitely a problem. // Enable the following code to see how often they crop up.
I guess it could be to stop GCC from spitting out warnings, I didn't think of that. Hmm.
To get back to my point: Look at Player and some of the other Point3F heavy classes. Their constructors are littered with all these Point3F's being assigned to Point3F (0, 0, 0). This not only clutters the code when it could be done implicitly in the constructor of Point3F, but is also (though the difference is very small) less efficient than initializing those three values in the Point3F with a initializer list.
#6
10/21/2012 (2:58 pm)
Not sure why it was added only for Linux, but by looking back in history upto TGE 1.3 it's there, so it may be that it was added in earlier days of Torque, or even from V12. 
#7
10/22/2012 (1:10 am)
That code is very old and predates TGE 1.3. TBH I wouldn't worry about performance implications unless you suddenly find 90% of CPU time is spent on initializing Point3F's.
#8
10/23/2012 (12:15 am)
Quote:These are not the initializers you've been looking for...move along...Source:James Urquhart
Torque Owner Demolishun
DemolishunConsulting Rocks!