Jump to content
Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    217151

Untitled

Sign in to follow this  
Mushu

70 views

Okay, yeah, I'm giving up on that GUI article. There just seem to be too many flaws in the system that I'm too lazy to fix (fonts are a big unaddressed issue, and there's this other weird problem which I'll get to later). So yeah. Fuck it :(

Final version of article
Source code to everything

Anyway, so I was writing an implementation of the Falling Sand Game, and I had decided to just write a generic scriptable celluar automatae whachamacallit with Lua/Python bindings or something.

Well, the first step was to shuffle together an expandable prototype interface using existing components. And it worked, until I attempted to add a dynamic array (read: vector) of button instances.

For some reason, my debugger (MSVC8) shits all over itself in the event code. Its an access violation (which I'm used to) when the button receives an event, so I'm like "oh, must be passing bad data somewhere". So I pop open the variables viewer and find this -



So I'm like 'what the fudge', because look what my tooltip says -



Okay, so here's what we know - there are apparently two instances of this variable 'i'. One of them is bad, we know that. But according to the tooltip text, we're not using that one so who gives a damn.

Actually, I just found out where that damn 'i' is coming from (a different scope lol). Lets see if you can spot it without the debugger.

switch ( e.state ) {

case e.MOUSE_MOVE:
for ( MouseMoveListType::iterator i = _movelist.begin();
i != _movelist.end(); ++i ) {

if ( ( *i )->onMouseMove( e ) )
ret |= EV_EAT;
}
break;

case e.MOUSE_ENTER:
for ( MouseMoveListType::iterator i = _movelist.begin();
i != _movelist.end(); ++i ) {

if ( ( *i )->onMouseEnter( e ) )
ret |= EV_EAT;
}
break;

case e.MOUSE_LEAVE:
for ( MouseMoveListType::iterator i = _movelist.begin();
i != _movelist.end(); ++i ) {

if ( ( *i )->onMouseLeave( e ) )
ret |= EV_EAT;
}
break;
}

return ret;
}

I'll give you a hint - if the error was during a MOUSE_LEAVE event there would be 3 'i's.

That's right - somehow the fuckers are propagating out of scope. Now, this is an annoying part of the debugger, but should that affect the code? Not really...

So I'm completely stumped as to what the problem is, exactly, and why its crashing.

Well, I'm still working on it. GAH.

Before I conclude, this is how I'm dynamically "allocating" buttons on the stack. Tell me if this is improper usage -

void addColorButton( std::string caption, ColorType color ) {
_buttonList.push_back( ColorButton( _gfx, color ) );
ColorButton* pButton = &_buttonList.back();
pButton->setCaption( caption );
pButton->setDim( 1, 1, 60, 20 );
_window->addComponent( pButton );
}


Because this is the code which is causing the problem (bad pointer). I was under the impression that this was valid (and using other container types - _buttonList is a vector - has no effect).

Thanks guys :(
Sign in to follow this  


4 Comments


Recommended Comments

I take it inner scopes don't solve the problem?



switch ( e.state ) {

case e.MOUSE_MOVE:
{ // begin scope
for ( MouseMoveListType::iterator i = _movelist.begin();
//...
}
break;
} // end scope
case e.MOUSE_ENTER:
{ // begin scope
for ( MouseMoveListType::iterator i = _movelist.begin();
// ...
}
break;
} // end scope
case e.MOUSE_LEAVE:
{ // begin scope
for ( MouseMoveListType::iterator i = _movelist.begin();
// ...
}
break;
} // end scope
}

return ret;
}





And also

void addColorButton( std::string caption, ColorType color ) {
_buttonList.push_back( ColorButton( _gfx, color ) );
ColorButton* pButton = &_buttonList.back();
pButton->setCaption( caption );
pButton->setDim( 1, 1, 60, 20 );
_window->addComponent( pButton );
}




What happens if the vector expands and moves all it's Objects arounds in memory?

_window's pButton will reference invalid memory...

Hope this helps.

Share this comment


Link to comment
Yeah, I realize the problems associated with vector-iterator invalidation, but the problem persisted when using a list. The only solution I can think of is to allocate the buttons on the heap (which I didn't really want to do) and then to just store their pointers in a boost::ptr_container or something.

We'll see. I'm too busy getting drunk this weekend to get any work done :)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!