Difference between Development and Deployment?

Member
Posts: 49
Joined: 2006.07
Post: #1
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...
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #2
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. Smile
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #3
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?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
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 Wink ) 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
Quote this message in a reply
DesertPenguin
Unregistered
 
Post: #5
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?
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #6
OneSadCookie Wrote:The difference between "Debug" and "Release" ( you should update your Xcode Wink )
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.
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #7
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.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #8
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. Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
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.
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #10
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. Smile

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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #11
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 Wink . 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
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #12
Thanks for all the suggestions. In the end, Xcode 2.4 fixed it.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #13
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 Wink
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #14
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?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  XCode 3.0 deployment AdrianM 3 3,890 Jan 10, 2009 08:34 AM
Last Post: AdrianM
  What's the difference between FMOD and mikmod? ThrottleMonkey 5 3,715 Apr 30, 2003 04:08 PM
Last Post: Mars_999