I get the basic idea of the difference between a development and deployment build, as for why you would want to have the two different modes. From reading Apple's docs and things I've found on Google, I get the basic advantages of each, but I haven't been able to find out what about the underlying functionality causes some of the weird effects I've been getting.
Does Development mode change the way that extern works, or mess with inheritance in C++? I have a bug that shows up only in Development mode, and am trying to decide whether I have a problem with memory management that hasn't shown up yet in Deployment, or if this is just some Development linker error.
I have a class called Camera, which is built on top of a class called polarObject. A polarObject is anything with a location described in polar coordinates and angular velocity (my camera only orbits the scene, it doesn't not slide side to side). In Development mode, arguments to the Camera class's constructor don't get passed on to the polarObject's constructor. It just gets junk data for arguments, so the camera winds up placed right at the very center of the scene where it can't see anything.
In my various attempts at debugging, I've established that the Camera constructor gets the right arguments, the polarObject's this pointer stores the same address as the Camera's this pointer, and I can hack it to work for my current purposes by just hard-coding the values I want for the camera into the polarObject constructor. (That means I can't use polarObject for anything else though, so I need to fix that)

My code:
in globals.h:

Quote:extern Camera camera;

in camera.h:

Quote:class Camera: public polarObject
{
public:
//constructor with default arguments
Camera(GLfloat rad=30.0f,GLfloat horiz=0.0f,GLfloat vert=0.2f) : polarObject(rad,horiz,vert,kClamp) {}
...
};

in camera.cpp:

Quote://Definition of global variable declared in "globals.h"
Camera camera;

in polarobject.h:

Quote:class polarObject
{
public:
//Constructor with default arguments for angular velocity
polarObject(GLfloat rad, GLfloat horiz, GLfloat vert, char clampMode, GLfloat radVel=0.0f, GLfloat horizVel=0.0f, GLfloat vertVel=0.0f);
...
};

in polarobject.cpp:

Quote://Implementation of constructor
polarObject::polarObject(GLfloat rad, GLfloat horiz, GLfloat vert, char clampMode, GLfloat radVel, GLfloat horizVel, GLfloat vertVel) : clampMode(clampMode)
{
//cout statements here show the arguments having junk data
loc[0]=rad;
loc[1]=horiz;
loc[2]=vert;
...

//my hack to temporarily make it work
loc[0]=20;
loc[1]=0;
loc[2]=.2;
}

If I'm doing something stupid with the way the files are linked together, let me know. Otherwise I'll keep looking for some sort of pointer abuse...

I'm not 100% here, but I think you need to go Camera camera = Camera(); in camera.cpp, otherwise the constructor won't get called at all.

I also have a hunch that you're hit by the RIIA problem, but try that fix up there first. If not, I'll have a great Think about it.

Thanks, but the explicit call to the constructor doesn't seem to make any difference. From cout statements, I know that the constructor to both Camera and polarObject are called but the arguments to polarObject are wrong.
What is the RIIA problem? From looking on google my best guess is that is has to do with variables going out of scope, but that shouldn't be an issue with extern, right?

Fenris Wrote:I'm not 100% here, but I think you need to go Camera camera = Camera(); in camera.cpp, otherwise the constructor won't get called at all.

This is incorrect; creation of a C++ object (locally, globally, via new, or via new[]) will always call a constructor.

The difference between "Debug" and "Release" ( you should update your Xcode ) is that debug mode adds debugging information (which won't change the behavior of your program), and does no optimization (in fact, anti-optimization to make it easier to debug). That will change the behavior of your program.

I don't see anything wrong with the code you've posted, but that doesn't mean much... I could be blind, or the error could be not in the code that's here.

Make sure you've got your warnings turned up to 11: http://tips.onesadcookie.net/tips/publis...ning+Flags

Just for fun, try explicity setting the constructors arguments.

e.g. in camera.cpp:
Camera camera(30.0f,0.0f,0.2f);

Also, what is kClamp in this line:
Camera(GLfloat rad=30.0f,GLfloat horiz=0.0f,GLfloat vert=0.2f) : polarObject(rad,horiz,vert,kClamp) {}

polarObject takes 7 arguments, 4 without defaults. camera only has 3. Camera has not been fully constructed yet so you should not access any of it's memebers.

Try adding a default to kClamp and instead using:
Camera(GLfloat rad=30.0f,GLfloat horiz=0.0f,GLfloat vert=0.2f) : polarObject(rad,horiz,vert) {}

BTW - Are rad,horiz and vert are only declared in polarObject, or are they also redeclared in Camera?

OneSadCookie Wrote:The difference between "Debug" and "Release" ( you should update your Xcode )

That's interesting-- I have Xcode 2.3. Is it meant to say "Debug" and "Release" under "Set Active Build Configuration"?

So far I still have no leads. I fixed all the new warnings and added explicit arguments to all the constructors, but they still get lost.

DesertPenguin Wrote:BTW - Are rad,horiz and vert are only declared in polarObject, or are they also redeclared in Camera?

They are arguments to the constructors of both, but their is no permanent field on either object with any of those names. The arguments rad, horiz, and vert get copied into spots 0, 1, and 2, respectively of

GLfloat loc[3];

which is declared in polarObject and is not redeclared in Camera.

Try declaring the Camera inside a function, and set a breakpoint on the same line. Then step into the constructors and see exactly where the values go bork. Right now, there are quite a few possible leads: the nestled constructors, declaring a global, the default arguments... See what good ol' GDB can give you.

ia3n_g Wrote:That's interesting-- I have Xcode 2.3. Is it meant to say "Debug" and "Release" under "Set Active Build Configuration"?

The new names will only be used for new projects. There's no functional difference between the old and the new.

Fenris Wrote:Try declaring the Camera inside a function, and set a breakpoint on the same line. Then step into the constructors and see exactly where the values go bork. Right now, there are quite a few possible leads: the nestled constructors, declaring a global, the default arguments... See what good ol' GDB can give you.

Well, I actually already know that the arguments go bad in the call to polarObject, and they only go bad if it is extern and in Development mode, but not if it is static or local, and not if it is in Deployment mode. That's why I am thinking this has to be something to do with how Development handles global variables. Or could it be possible that Development just arranges things differently in memory and the camera is getting messed up by some problem with pointers I have elsewhere? I doubt that because it happens within the nested constructors, so none of my other code has a chance to execute to write to the wrong part of memory.

When ZeroLinked, the behavior of globals can be quite different. You can try disabling ZeroLink (remember to really kill it dead, it's like a roach. Check the detailed build log to be certain) to see if that helps, though I'd still consider your code buggy if it does help . If you're getting any linker warnings in the release build about duplicate definitions or anything like that, you should make sure to squash them.

I'm sure you already know this, but: http://tips.onesadcookie.net/tips/publis...bjective-C

Thanks for all the suggestions. In the end, Xcode 2.4 fixed it.

Interesting...

Yet another reason not to use C++:

#948,382: The language is too complicated for them to make a bug-free compiler

As if there weren't enough already

This is straying from the original topic of the thread a bit, but are you saying that Cocoa/Objective-C don't have these sorts of problems, or don't have as many of them?

Objective C is a *much* simpler language, so the chance of a compiler bug is somewhat lower. It's also much more used by Apple themselves, so they're much more likely to discover any issues before shipping the compiler.

That said, in general, C++ is more used, and therefore more likely to get fixed by the community.