On Mon, Mar 2, 2009 at 12:55 PM, Michael Sullivan <[email protected]> wrote:
> > I keep getting these access violations, and the line the program seems to
> > stop on is
> >
> > imageMapFileName is set with
> >
> > void
> > Character::setIMFileName(string fn) { imageMapFileName = "./" + fn; }
> >
> > That method is being called, but for some reason, imageMapFileName is not
> > being set. When I set a breakpoint on the setIMFileName line and run it,
> > down in the Watch window it says " imageMapFileName CXX0069: Error:
> > variable needs stack frame". What is this stack frame? When the
> > getIMFileName method gets called and the program fails, this is in the watch
> > window:
Are you debugging a "release" build? If yes, then it is possible that
the compiler
might have inlined the function call away in the interest of code
optimization which
would explain the CXX0069 error you are getting (no stack since it is
not a function
call). If you have an object address or a pointer then you might be
able to use an
expression such as this to inspect "imageMapFileName" in the watch window:
((Character *)0xABCDEFGH)->imageMapFileName
or
pObj->imageMapFileName // where "pObj" is a pointer to a
// "Character" instance
I say "might" because "release" build debugging does not really work well (which
is by design since "release" builds are not meant to be debugged) and your
mileage might vary.
> I think I've got it, but I need to ask a question first: Ally inherits from
> Character. In Java, this would mean that Ally would have all the public
> methods that Character has. In C++ I cant take an Ally ally and say
> ally.getIMFileName(), can I? If that's true, then I think I know what's
> wrong...
If you use "public" inheritance to inherit "Ally" from "Character" then all
public methods in "Character" will be callable through "Ally" instances, i.e.
if you inherit "Ally" from "Character" like so,
class Ally : public Character
then you can call "getIMFileName" from an "Ally" instance. If you use
"protected" or "private" inheritance then you can't.
As for the access violation, your best bet is to use a "debug" build (if you
aren't already using one) and let the debugger break into the line at which
it crashes and inspect the call-stack to see what's going on.
--
Ranju. V
http://blogorama.nerdworks.in/
--
